Just like a session cookie is long-lived? At least with a refresh token you can keep things like specific roles etc. out of it and treat it much like an opaque session cookie (perhaps just containing nothing but the user's ID, which can be looked up to get the real roles/permissions for the short-lived access tokens).
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?
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...
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.
Yes, but also no. Typically you might need a valid jwt on every request, but a refresh token request on a different (hot) path only every 5 minutes per user. And revalidation might easily query a whitelist (sql/db - is user valid for login/refresh) or a blacklist (is refresh token invalid?).
The jwt being valid 10 minutes (accounting for clock drift) might be a problem - but probably sufficient for many applications?
