In the case of a serious attack, the blacklist should be every token. You can still handle this quite nicely with JWT by rotating the previous verification key. Depends on systems and configuration, this can be as easy as changing the HMAC private key or push a new RSA key to every verifier.
Re:Biscuit Authorization
by physicsguy on Thursday December 14, 2023 @07:34AM
(#38640676)
I've already seen one company adopt Paseto tokens as though this is some sort of magic bullet.
A simpler, but less targeted approach that works in case you're not tracking token issuance by ID is to maintain a list of maps of entity (e.g user) ID to minimum issue time. This way you can revoke all earlier tokens for a user ID with a single record, and not have to keep track of issued tokens.
By the nature of the problem you have to store some kind of a list of tokens. Either a black list as with JWTs or a white list as with classic session tokens. There is no way around it. This makes both approaches practically the same.
One can argue that the black list will in general be shorter than the white list, but in a case of a serious attack, would it really be so?
I am afraid that the community will now abandon JWTs and move to biscuits, macaroons, buns and meringues as they did with classic session tokens, throwing away the tools and security practices.