Hacker News new | ask | show | jobs
by motorest 437 days ago
> now you need to synchronize a list of sessions everywhere..

No. You just maintain a single deny list.

> which is exactly what we were using JWT to avoid...

JWTs were designed to allow servicss to do stateless checks. Originally this meant clients getting single-use bearer tokens, or worst case scenario short-lived tokens. Revocation lists are only relevant if JWTs are explicitly used in a way that goes against their design goals of being short-lived.

Nevertheless, you are also wrong: JWT denylists have absolutely nothing to do with sessions. The are a list of what JWTs should be rejected by resource servers. A client can and does handle many JWTs throughout their session, whereas resource servers only need to periodically refresh that list and check if a JWT ID is in it or not. This does not make JWTs more or less stateless.

1 comments

If there is a deny list, and you have multiple services, you either do need to sync it or have a service fully responsible for this, and this does come with the burden of dealing with consistency guarantees, so it’s not as simple as “periodically refreshing the list” especially if the need is high for accurate revocation information, like if a service is dealing with very sensitive data. Handling the list is arguably a bit easier than dealing with a bespoke session, since it’s less data to handle and can be scaled more easily, but I think it’s disingenuous to argue that you “just need to maintain a single deny list”.
Revocation checking could be moved to the proxy level.
> If there is a deny list, and you have multiple services, you either do need to sync it or have a service fully responsible for this, and this does come with the burden of dealing with consistency guarantees (...)

No. Revocation is typically implemented as a shortcut to token expiration. Token expiration involves a grace period. The goal is to arbitrarily reject a long-lived token before it's expiration.

> (...) like if a service is dealing with very sensitive data.

No. That's why single-user tokens are used.