Session cookies are generally server-side stateful and trivially revoked, which is why we don't worry as much about their lifespan. JWTs are generally stateless --- that's one of their top-promoted features --- and are, in fact, difficult to revoke.
I still don't see how this makes it significantly more difficult to manage or revoke a JWT than a server-side session. For the session you remove it from the DB, and with a JWT you add it to a blacklist.
About the same amount of effort from my perspective, and revokes are probably extremely rare by comparison to issues or validations of tokens/sessions...
Re:Anatomy of a JWT
by JamesSwift on Tuesday March 01, 2022 @08:58PM
(#30522733)
Session cookies are just a password for the server to lookup the information _on its side_. So when you revoke the server's portion of the session, it no longer exists even though the cookie is "valid".
Right, I understand that. JWTs can be revoked using a similar server-side mechanism - just that it's more of a blacklist instead of a whitelist.
And since you are likely adding more sessions than you are manually revoking them, why not optimize for that flow and use JWTs? Sure they may not be 100% stateless if you have to maintain the blacklist, but I'd say 99.9% stateless is still preferable over 0% stateless for many applications.
The main advantage of JWT, at least the advertisement historically, has been they are stateless and scalable, but that black list makes the system stateful again and you loose out on most(or all scalability) benefits. I think how much you loose depends on the specifics of the implementation, you definitely seem to loose any simplicity of design though from what I have read/worked with.
I think it's dubious to call refresh tokens "difficult-to-revoke" but call sessions easy to revoke. Both require some kind of state. The difference is that you are (hopefully) doing far more grants and checks on tokens than you are doing revokes - so why not optimize for that flow?