Deploying to multi-node / cluster environments like k8s and impact on sessions, etc.

[205g0]

Describe the problem

From the docs, in particular the part about $app/stores, it is not clear how we can deploy Sveltekit in multi-node environments such as Kubernetes.

With express I would store session data on a database, single instance or replicated and get always the session from there. Hence, I can scale express indefinitely since it stays stateless. Is this also possible with SvelteKit? Meaning Svelte's session store would always get the session data from a db before it answers the request?

A simple chart of such an architecture:

The problem behind: Even if some cluster orchestration software allows to create sticky sessions, so requests hit the same node, it is not always possible to solve this problem on the cluster layer (e.g., when using BGP, autoscaling down, etc.) and it's in general more complicated than just storing the sessions on the db if latter is fast.

Describe the proposed solution

A paragraph in the docs stating if deploying to a multi-node cluster is possible and/or what trade-offs would be encountered (assuming the cluster layer does not offer sticky sessions).

Alternatives considered

No response

Importance

would make my life easier

Additional Information

No response

[rmunn]

Session handling is left up to you, using the provided hooks. In the configuration you're describing, you would write a handle hook runs first, takes the request, and extracts (for example) a session ID from a cookie and attaches that session ID to request.locals. Then the getSession hook would run, talk to the database and fetch the session data given the session ID, and return an object with the session data that the client should see (which will populate the $session store on the client). (Note: You could also do the DB query in the handle hook rather than the getSession hook, depending on whether you want that session data loaded for endpoints or just for pages. The best way to do that will depend on your app and what precisely you store in the session.)

Which means that scaling up would not be a problem, because session data would always be fetched from the DB service no matter which node answered the request.

[Angie9218]

Na

[205g0]

Ok, glad to hear and to summarize:

• To "sessionize" a page => in handle, do extract the session ID from the cookie and enrich request.locals, in getSession get session data from db and return in order to populate the $session store in the client
• To sessionize an endpoint => do all above in handle and before returning the endpoint's response; reason: the response depends very much on the session data in a typical app, .e.g,, the settings json of an individual user

Did I get it right?

[Angie9218]

Yes

[CaptainCodeman]

You can improve your scalability further by making the session cookie data into a bearer token (JWT)

This means you only need to do the database lookup when you are signing in or refreshing the access token, rather than on every single HTTP request.

The request effectively contains all the data needed to create the response (from a user info / permission perspective). The token is typically signed so you can verify that it hasn't been tampered with but this is a quick operation without any network request or database lookup (you should really do this even if using the DB sessions, so it's not extra work).

[lkj4]

The token is typically signed so you can verify that it hasn't been tampered with but this is a quick operation without any network request or database lookup

But how would I invalidate existing JWT tokens out in the wild if "it is just a quick operation without any network request or database lookup"?

[CaptainCodeman]

You can use two tokens, an access token and a refresh token. The access token is shorter lived and re-generated periodically using the refresh token. The time period it's valid for depends on the tolerance that makes sense for your app, it could be an hour for instance, which means changes to permissions would take half-an-hour on average to be reflected. But for some operations, you can insist that the token has to be refreshed, to check for access being revoked etc...

This will maybe explain it in more detail than I can:
https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

[lkj4]

This sounds like OAuth and all its complications. Why not just one short-lived, rolling token? Rolling means, that its expiration date gets extended on every request by a short time period. And in the case of invalidation, not anymore.

[CaptainCodeman]

It is, but it's not implementing OAuth completely, it's more just "consuming it as a client". The reason you wouldn't use a single token is that at some point a request will be made where the token has expired and as you say, what then? All you can do is re-authenticate the user at that point so the experience becomes poor OR you have to make the expiration period longer than you really want.

The access + refresh token has been thought through and allows for longer lived sign-in states while also shortening the lifetime of the access token and providing a mechanism for periodic re-checks.

[lkj4]

Ok, so you say...

• have a 1h access token with the userId encoded, so at least I save one db request to validate the session and getting the user id
• the refresh token has just the refreshTokenId encoded and is saved/read from the db

=> in a emergency I just invalidate the refreshToken by changing some field or deleting it and in the worst case, the user/bad actor has still max. 1h access to the system, not great but in specific use cases bearable

if I got it right, what I still wonder: I assume that I cannot save more stuff, e.g. user settings, in the access token in order to save further db requests, too small in size and I have to save stuff both to the token and the database which creates just a more complex system. Then, I have the benefit of just having one db request less? If I have tons of microservices which all authenticate all the time, this would add up. But even then, if I use some replicated DB with enough RAM and smart caching in the samte datascenter, I shouldn't see a significant latency by using just the db as a session store with one access token which is saved/read on the db. And I would get immediate invalidations and a much simpler system. Hope I missed something. but pls correct me if I am wrong.

[CaptainCodeman]

You save more than 1 db request - you save doing any db lookup for session on every request.

If something is really critical, you can insist that an access token is a freshly minted one to diminish any risk from the 1hr window but you can also keep a cache of revoked tokens which can be in-memory and quicker to check than storing sessions in a db for all users (you're just handling rare exceptions). And you can always make the access token 10 minutes, or a day, whatever makes sense for your system.

You can store additional claims in a token, to avoid looking things up. These might be flags (e.g. admin) or roles - whatever you need to be able to approve a request without doing an extra lookup.