3 ms·
So don't do that - and you're stateless! I can't recall the last time I used a "Logout" button anywhere. I no longer visit internet caffees...
by tasuki 4mo ago
So don't do that - and you're stateless!
I can't recall the last time I used a "Logout" button anywhere. I no longer visit internet caffees...
- icantevenhold 4mo agoEvery authentication system i ever implemented (and I worked on many) needed some way to invalidate sessions regardless whether it’s self service for the user or not. And once you do you need some state and then JWTs don’t make much sense anymore. There are of course many valid use cases for JWT so “JWT bad” is a very reductive take
- tasuki 4mo agoIt's curious: very few authentication systems I ever implemented needed some way to invalidate sessions.
- tptacek 4mo agoYou either reissue tokens constantly, every couple minutes or so, or you have to reliably invalidate.
- tasuki 4mo agoMaybe you do. Why would I have to do that?
- tptacek 4mo agoBecause it's bad to ship products where a compromised token can never be recovered from. Revocation is the essential hard problem in authentication/authorization.
- tasuki 4mo agoI guess I just can't see the actual path here. How does a token get compromised in a way the victim finds out before the attacker makes ample use of the compromised token? From my pov, when the token gets compromised, you've lost already. Note the auth systems I create usually do not process payment info and contain very little personal information (an email). I still think I'm fine without revocation mechanisms.
- SnowflakeOnIce 4mo agoLogout functionality is not the only use case for token invalidation. Another significant one is to revoke a token that has been exposed, like inadvertently pushed to GitHub. In that case you want to invalidate the token to a avoid unauthorized access to your service. With vanilla JWTs, you have no way to do this! But then if you add revocation checking on top (which people do), your JWTs are no longer stateless.