How to properly do auth checks in SPA mode?

[arkmech]

Following this: https://svelte.dev/docs/kit/single-page-apps

In my root layout.ts,

I have

export const ssr = false;

The load function here is running my auth checks (api call to separate server) using redirect()

I know that generally if I had a SvelteKit server, I would use hooks.server.ts. As you don’t need to do await parent() is every load function nested in every nested layout.ts and page.ts.

export const load = async ({ parent }) => {
  return parent()
} 

So I thought in SPA mode it would make sense to use hooks.client.ts, but based on docs: https://svelte.dev/docs/kit/hooks unfortunately handle is only under Server.

Seems like hooks.client.ts is really only for handleError.

Am I doing auth check correctly then in layout.ts and and every page.ts and layout.ts needs to return parent() in load function?

Note: I am getting some stale data on updating the session data. Can’t use Tanstack query in layout.ts so these auth calls can’t be invalidated on mutation operations. This session data I am referring to is being returned from my root layout.ts

[gterras]

What are you protecting here that your server can't? To avoid repetition you can customize your fetch function.

[gterras]

In Sveltekit SPA implies disabling SSR, so everything in the build is readable anyway. So as I understand your situation either :

• private data comes from your server > client calls to server carry some auth token anyway > server returns either data or 401 > client handles navigation according to this (via a fetch wrapper for instance). In this situation the "auth check" is more of an "auth flow", and can be done initially on mount for faster result (and/or getting some user profile data) rather than on every navigation (since subsequent server fetches will then handle this for you).

• private data is in your build, and any protection is vain.

[arkmech]

In Sveltekit SPA implies disabling SSR, so everything in the build is readable anyway. So as I understand your situation either :

• private data comes from your server > client calls to server carry some auth token anyway > server returns either data or 401 > client handles navigation according to this (via a fetch wrapper for instance). In this situation the "auth check" is more of an "auth flow", and can be done initially on mount for faster result (and/or getting some user profile data) rather than on every navigation (since subsequent server fetches will then handle this for you).

This is very standard web architecture...The server I am using is separate from the client as stated in OP. I think you need to read up on 3-tier or N-tier web architecture before we can have a discussion here.

"auth check"? "auth flow"? are we just discussing semantics here? the client makes a call to an external auth server and redirects based on that. So you would call Svelte's onMount on every page?
There needs to be equivalent functionality on hooks.client.ts like hooks.server.ts for global auth check. Its like middleware.
The point is there is no good way to do auth checks on SvelteKit SPA mode.

• private data is in your build, and any protection is vain.

It is generally assumed there is no private data on the client...all private data on server.

[harunzafer]

@arkmech I agree that there should be some auth check for an SPA even if without authentication those pages can't fetch any data from the server. What I do is overriding axios (or fetch) so that whenever we get a 401 from the API, we redirect to /login. Of course this is not enough. I also use a store to track the authentication status and use that store from pages that I want to protect. For example /(protected)/+layout.svelte contains an onMount() that check the auth status by calling the /users/me endpoint and inside we have and if (auth) render children else don't render and redirect logic. I don't use +layout.ts, load functions etc.

Unfortunately, SPA is still like a second class citizen for SvelteKit. And everyone has their own auth solution. I think Svelte team should provide some recommended official approach to this in their documentation.

SPA is way more developer and user friendly and there is almost no point of using SSR if you don't need SEO (most dashboards, SAAS apps etc.) I've tried both and loving SPA mode so far.

[arkmech]

@arkmech I agree that there should be some auth check for an SPA even if without authentication those pages can't fetch any data from the server. What I do is overriding axios (or fetch) so that whenever we get a 401 from the API, we redirect to /login. Of course this is not enough. I also use a store to track the authentication status and use that store from pages that I want to protect. For example /(protected)/+layout.svelte contains an onMount() that check the auth status by calling the /users/me endpoint and inside we have and if (auth) render children else don't render and redirect logic. I don't use +layout.ts, load functions etc.

Unfortunately, SPA is still like a second class citizen for SvelteKit. And everyone has their own auth solution. I think Svelte team should provide some recommended official approach to this in their documentation.

SPA is way more developer and user friendly and there is almost no point of using SSR if you don't need SEO (most dashboards, SAAS apps etc.) I've tried both and loving SPA mode so far.

Appreciate your input, yeah I only chose SPA because one less server to manage. I hope the SvelteKit team comes up with a SPA way of hooks.server.ts

[gterras]

@arkmech you carefully ignored every points of my posts that could have help reduce your confusion... What you call a "middleware" here cannot magically work without complex work that wouldn't match every case anyway and would be misleading as hell. There are also numerous way to work around it so I'm not sure about some change on here anytime soon.

[mateothegreat]

I can directly relate to your position @arkmech.. spa's are an under valued pattern and a lot of things get lost in translation 😬

The whole reason this thread exists is that, in SPA mode, there isn't first‑class handle‑style hook on the client. Folks are ending up duplicating auth checks in every layout or load function, or wiring up ad‑hoc onMount redirects. That works, but it’s brittle and easy to miss in a growing app and perhaps it's time to re-evaluate architectural technology selection.

Now, if you want something that feels closer to the "global middleware" pattern (which is what I believe is being asked for here), svelte5‑router might be worth a look (I cranked this out for this very case). It gives you pre & post navigation hooks out of the box — meaning you can run your auth check before a route is allowed to resolve, trigger analytics, or other side‑effects beofre/after navigation. In practice, that means you define the guard once and every protected route respects it.

It won’t replace SvelteKit’s core router, but for projects committed to ssr = false, it provides the missing client‑side guard layer the you and others are wishing existed. It's opt‑in, lightweight, and gives you breathing room.

I threw up a snazzy demo at https://demo.router.svelte.spa/protected which is basically:
https://github.com/mateothegreat/svelte5-router/blob/main/demo/src/routes/protected/manage-account/manage-account.svelte#L94.

Feel free to ping me if ya have questions or concerns!
-Matthew ✌️