Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Right, but once you're checking for invalid nonces, your token format is now stateful; it's lost the primary benefit of statelessness, which is continuing to function under network partition between the application server and the token state store.
 help



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...


Logout 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.


Every 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


It's curious: very few authentication systems I ever implemented needed some way to invalidate sessions.

You either reissue tokens constantly, every couple minutes or so, or you have to reliably invalidate.

How can you provide a stateless logout (that invalidates credentials rather than simply forgetting them client side)?



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: