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.

▲

littlecranky67 6 hours ago | parent | next [-]

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)

▲

10000truths 3 hours ago | parent [-]

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.

	▲	littlecranky67 3 hours ago \| parent [-]
		> 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.

▲

matt-p 6 hours ago | parent | prev | next [-]

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.

	▲	littlecranky67 6 hours ago \| parent [-]
		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.

▲

mewpmewp2 5 hours ago | parent | prev [-]

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.