JWT Token Revocation
Discussions focus on challenges and strategies for expiring, refreshing, and revoking stateless authentication tokens like JWTs, including trade-offs between security, server state, and short-lived tokens.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Why not make them 2 use tokens?Not quite as secure, but way better than never expires?
You can't revoke a token if you have no server-side state to purge. Relying on timeouts is a fairly crude way of going about it.
For number 2, you could expire them by encoding some identifier based off a hash or key tied to the user object. Change that object and have the server reject the token if that meta data no longer validates.
Tokens can expire?! That can't be legal...
Why wouldn't the system require each refresh of the session token to require additional authentication? Then a stolen token can't easily be refreshed.
With this method isn't the downside that you have to invalidate all tokens, and not just the attacker's tokens?
It’s a trade off dude. You trade off the ability to revoke a token instantly for fewer backend calls. For most parts of your site (99.9%) that trade off is fine. For the parts where it isn’t fine you... call the auth server every request.JWT doesn’t mean you give up anything....
I'm curious, which situations are short-lived tokens not an option?
Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.
That's fair, although it doesn't allow tokens to be revoked or to expire. For that you'd need to store at least some unique part of the payload you're signing, and then you have O(n) storage requirements again, right?