Session data lookup is one select to database that gives 0..1 rows and uses index. In most cases this is not something you need to worry about.
Session data lookup is one select to database that gives 0..1 rows and uses index. In most cases this is not something you need to worry about.
I agree. The storage space, however, is a different story. Your session DB can grow huge, depending on your session lifetime and your users logout behaviour. Plus, it is a concern in a distributed system (i.e. a token can be validated on every node, vs. a session lookup must be globally in sync)
1. For the vast majority of CRUD apps, active sessions will be a very small fraction of the actual storage requirements. A SaaS with 100K MAU may have only 100 or so active users at any given time.
2. Sessions by definition are ephemeral. A database should not be necessary at all, an in-memory cache should suffice.
3. If you really need to distribute session data across multiple nodes, just propagate them asynchronously. Authentication and authorization are semantically idempotent operations. Having to possibly re-auth when making a cross-region request within milliseconds of logging in might be mildly annoying for the user, but consistency isn't a deal breaker here.
> 3. If you really need to distribute session data across multiple nodes
What you mean, "if" - you will need that once you are international. You can't afford to verify every http request against a centralized session store when you have users in Australia, US, Europe, Japan etc. You can't beat the speed of light. My point is, replicating revocation lists that are append-only, only a small megabytes, and can be publicly known, is always easier than syncing session databases for a complexity standpoint.
Can even put it in redis too, if you have performance issues from looking for it in memory then you have probably have more users than google.
What if you have two servers, one in japan and one in central europe? Where do the sessions live?
With JWTs, you would only need to replicate your revocation list of the last X hours (X being your JWT default lifetime) and probably be in the megabytes for the total list. Easy to replicate that ever 5-10seconds to all your locations.
You probably don’t need to replicate it? The users hitting your Japan server aren’t going to suddenly hit your central eu server?
Except when they do...
If you have multiple services in multiple locations however, you may want to replicate this data, so in this case revocation list as it's much smaller would be far easier to replicate for much less latency overhead.
Then you have to replicate all the other data too? I don’t see the issue.
That is not automatically given in any system and depends on the system. Authentication, however, is a minimum required feature in most system that would introduce latency. Just imagine sending each and every http request from a user half way round the world to lookup the session - latency would be terrible.