Proper way to do auth in sveltekit?

[bojanv55]

Describe the problem

I have an app using sveltekit + java as backend. I use @sveltejs/adapter-static to pack svelte app and serve it from java server as .html files. I'm using simplest JWT token stored in cookie to do auth on the server. The question I have is - what is the proper way to do auth in this case?

This is option 1:

Here, client requests the page, and if he does not provide proper "Cookie: access_token=jwttokenhere" in the header, java server will redirect him directly to the /auth/login page and then the client will get that URL from sveltekit built files.

The problems I have here:

• If I issue goto("/"); command inside the sveltekit route, svelte does not care if user is authorized or not, it will redirect no matter what. So I have to use instead

if(browser){
  window.location.href = "/";
}

Option 2:

Here, index page is loaded from the server without any check if user authenticated or not. Then sveltekit needs somehow to know if user is authenticated. I saw that we can use here this method export async function load({ page, fetch, session, stuff }) as an interceptor, and check if some variable is set - if not then we redirect. So here, there is no logic from the server related to redirects - server would only return status codes 401 if not authorized.

The problems I see here:

• Even if that variable on client side is set - that doesn't mean that client is currently authenticated on the server (eg. jwt token expired etc). Then on the next fetch to the server, server will issue 401.
• If I put fetch call inside this load function just to fetch whoami endpoint for example - in order to see if currently authenticated - this is costly on every route change.

Describe the proposed solution

No solution. Just asking what are possible alternatives to described use-cases.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[CaptainCodeman]

I suspect the reason you've had no responses to this is because it's difficult to really make sense of the question.

I suggest as a first step you decide where auth is going to happen and how - is the auth state completely client-side (the sort you get if you use firebase' auth default for example) or is your app going to run server-side in order to decide if access to a page is allowed?

The problem with the latter is that it doesn't really fit with using the static-adapter - you don't normally have auth to restrict access to static pages of a site (unless it's 100% SSR) but instead to the data that those static pages may load. Presumably you want the auth to load data provided by your java app (?)

There are lots of options for handling auth and SK provides pieces to use to make it easier (i.e. the session mechanism) but the setup you describe is probably going to make it way more complicated than it needs to be.

First step is deciding if you need to use SSR, an SPA or hybrid (both), where the auth state will live, and where that auth state needs to be used to grant or deny access to anything. Once you have those you can then get into the specifics of how to implement things.

[bojanv55]

@CaptainCodeman OK, so this is something that I think would work pretty well, but I think that it is not 100% supported by the svelte:

What is think is currently not there:

• Possibility to pack different js+html+css bundles based on roles (so, login bundle would be the one that is served for clients that are not logged in, then there is USER-bundle that has all the files allowed for USER-role logged in users, and finally ADMIN-bundle). The point of this is that no one should be able to view-source or analyze admin/user js+html code before logging in).
• If fetch call to the server results in 401, there should be some interceptor in place that would redirect SPA page to login as soon as this happens (this functionallity is possibly already there or maybe easy to implement).
• goto(/) in svlete is not issuing another GET call, but I have to call window.location.href = "/"; in order to issue real GET to the browser. I guess this is actually how svelte works, so this is not a big problem in this use-case (not sure if there is some param like goto(/, request=true) in order to actually execute server request?
• In this setup, user after logging-in, with role=USER, will get all the SPA pages that are available to him. So even if lets say JWT is manually removed from the cookie, SPA will still function up to the point that fetch call is executed to the server. At that point, server will return 401, and SPA will redirect to login page. I guess this is not perfect, but I think that it has to be that way.

Now, my question is - is this kind of setup something that is normally implemented this way?

Responding to your questions - as you can see from this current setup, I guess it is both, so SPA + SSR, where SPA would be SPA-login-only, SPA-USER-role, SPA-ADMIN-role. AUTH state lives in JWT token on the client side. JWT token is evaluated on the server side when requesting any endpoint (no matter if it is localhost:8080/something or localhost:8080/api/something; the only difference here is that first one responds with 302 redirect to login pages, and second one responds with 401 Unauthorized).

[CaptainCodeman]

is this kind of setup something that is normally implemented this way?

No. This is not typically how auth is done on the web. I'm sure someone, somewhere does it, but you're going down a less-walked path.

Everything is usually possible so of course it's possible to do what you describe but there are no perceivable benefits over other approaches that are far simpler.

You have all this "detail" in the form of sequence diagrams but little real information of how it needs to work - what exactly is being protected? For instance, do the HTML + JS pages actually contain data such that they really need to be protected from being loaded or do they make requests for data which is what would actually need protecting?

Some of this lack of clarity may come from using the static-adapter, that doesn't mean that all the pages are statically rendered - it could still be a SPA that makes fetch requests, so you should describe what is actually going on rather than just describe it as that being the app.

[bojanv55]

Data protection (data rest APIs) are of course of the primary concern, but also there is possibility that some static data (lets say some phone numbers etc.) can be encoded inside HTML+JS that is served as a SPA from svelte-kit. This kind of data I would like to protect from anonymous access. Also, by limiting access in this way, we respect principle of least privilege, which is always a good thing to do.

And yes - those pages are actually SPA pages. How I understood static-adapter - lets say I have 3 routes: login, route1, route2. How I understood this is that svelte-kit will make one SPA app that is accessible from any of these 3 possible routes (which are actually files login.html, route1.html and route2.html). So if someone accesses /login, it will download login.html but also all the files to client needs to go to route1 and route2 without contacting the server again. If someone accesses first time /route1, server will also serve route1.html with html+js that has login and route2 pages to be accessible on client side without contacting the server.

Can you please describe what would be that lest-complex approach to this?

[CaptainCodeman]

I think your interpretation of "least privilege" is incorrect - IMO that's about only granting the roles that are necessary (i.e. don't make everyone an admin).

The easiest approach is not to try to swim upstream and make things more complex than necessary (as that is often worse for security). I'd simply follow the basic approach shown in the examples of using auth + SK session. It's really easy, works well and is secure, allowing checks on both the server and client.

PS: SK only downloads the JS + dependencies for the route you access so it gradually loads your app as you access new routes, not the entire app at once as you describe.

[bojanv55]

it is not that principle, you are right, but it is the same idea (whatever name you want to give to this principle - maybe "less you know - that better").

If that part in the "PS" is how it behaved it would be ok for me I guess. The problem is that my app on goto("/whatever") is not hitting server (which would be able to intercept the routing), but actually resolves the route on the client side. Maybe the problem is that I pack it as SPA application with static-adapter?