2 ms·
> Revocation is essentially the Achilles heel of JWTs By the nature of the problem you have to store some kind of a list of tokens. Either a black list as with
by ivanb 3y ago
> Revocation is essentially the Achilles heel of JWTs
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.
- deleted 3y ago[deleted]
- antran22 3y agoIn 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.
- physicsguy 3y agoI've already seen one company adopt Paseto tokens as though this is some sort of magic bullet.
- darkr 3y agoA 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.