[capn_duck]

Can you explain what this looks like? So each application that authenticates its requests using the jwt subscribes to a message queue and replicates the data in some database local to it? Then it checks that database each time a new request comes in?

[tehbeard]

Pretty much, with the type of local db/cache changing based on the amount of concurrent invalidation you expect.

The theory is that your list of prematurely invalidated tokens (expired by user before the token's own expiry date) is much, much lower than your active tokens, so you only have to check a requests JWT against this tiny subset, rather than every active session to confirm it doesn't exist.

It has its own unique failure modes where an invalidation doesn't make it to all listeners, so either you can expend effort to make it more robust (and it's again, less data to sync than the sum of all active sessions) or just live with some parts of the system allowing the token for a few minutes..I

Typically, unless you are at a very large scale, or dealing with offline clients, I'd stick to traditional cookies + session.

[capn_duck]

That makes sense. Thank you.

Honest question - What would you do to justify doing this over using cookie based sessions? Like, are there back of the napkin calculations you could do to find when one approach becomes comparable in performance to another? That's one thing in system design that I struggle with.

[monocasa]

Depends on how many invalidations you see. Some systems can get away with a message queue with an in memory copy of whatever's still in TTL with a bloom filter in front to make for a really cheap check. If you have more invalidations than a simple library implementation can handle, you do a similar thing with a DB like Redis sitting off to the side.