Yeah of course, but how does that relate to my point? With JWTs you don'T have a list of valid tokens as state, but only a list of invalid ones (revoked). But the list of revoked tokens in the last X hours (where X is your token lifetime) is always going to be smaller than the list of active sessions given a large enough user base. Hence my original point stands, that the lookup and storage costs are lower than on sessions. Whether or not sessions have session lifetimes does not change the fact at all.

▲

zsoltkacsandi 6 hours ago | parent | next [-]

> With JWTs you don'T have a list of valid tokens as state, but only a list of invalid ones (revoked).

Yes, and a lookup operation is a lookup operation.

Your database or data structure used for storing the sessions/JWT revocation entries won't really care whether you look for things that are active or things that are inactive/revoked. If you store it in the right database, both lookups will be O(1), so it is the same (or at least the difference is negligible), regardless of the size.

▲

littlecranky67 6 hours ago | parent [-]

The story changes if you have a distributed database. replicating a smaller revocation list (that is append only) that will never be more than a couple of MB, is easier to do accross distributed nodes around the world than keeping a larger, session state db replicated. Heck, your revocation list can even be public (it contains only a list of substring of a few bytes of hashes).

Syncing sessins can be done, no question, I would just think JWT+revocation db is easier to implement, yet robust.

	▲	conradludgate 4 hours ago \| parent [-]
		It can also be encoded as a bloom filter for very fast checks. Then you can defer to the replicated LSMTree that's stored replicated on your local node

▲

doctorpangloss 6 hours ago | parent | prev [-]

isn't it that you must have a revocation list in many cases? if you cannot get from N to 1 or 1 to 0 states, if you're just going from N to N-1>1, you haven't materially decreased your statefulness

▲

littlecranky67 6 hours ago | parent [-]

But the revokation list is always going to be orders of magnitude smaller than the list of active sessions.

▲

doctorpangloss 5 hours ago | parent [-]

that may be, but who cares how big or small it is really

if you are facebook sized, with 1b+ active sessions versus an alternative with 10m+ revocations... the kind of applications that reach this scale, they have enormous amounts of state anyway.

	▲	littlecranky67 5 hours ago \| parent [-]
		Everybody thinks Mag7 scale, but actually it is more relevant if you are a tiny webservice - but available world wide. If you need to match each and every http request from a user half way around the world against a central db, you can't beat the speed of light. If you can do authentication on each downstream server directly using crypto and JWT validation, you at least save that roundtrip to the session db. The revocation list is tiny (a few megabytes tops), append-only, can be public to the world, and thus easy to replicate to your downstream nodes. If you are a smaller gig, you won't have to bother with replicating your sessions and keeping them in sync globally.