This is a bug, not a feature, especially if you make your tokens long-lived. If your implementation is completely stateless, then there's no way to invalidate a token to allow a user to log out. If a JWT somehow gets stolen, the user has no way to terminate the stolen session.
At best, you could create a blacklist of tokens that have been invalidated, which would delete rows as time goes on and the tokens reach their natural expiration date to avoid the database growing forever. But at that point, it's no longer stateless.
Agreed! You should never make tokens long lived. Seconds to minutes is what we typically see.
"But won't users have to log in whenever the token expires?" Nope, that's what the refresh grant (in the OAuth world) is for. I am not as familiar with other uses of JWT, but I suspect there is a similar process that relies on the issuer for them.
> But at that point, it's no longer stateless.
Agreed, it is an architectural choice. You can choose the benefits of statelessness (scale) at a cost of revocation difficulties. You can get revocation, but you have to re-introduce state.
Is there some token solution out that that I'm unaware of that gives you statelessness and revocation? Would love to learn more about it if so.
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?
JWTs can totally store state. I've found good use cases for it and I've never understood why people immediately get up in arms about it - possibly conflating the concepts of JWTs themselves and OAuth 2.0. It's just a damned signed json blob. Trying to act like it's anything more is missing the point.
The statelessness being discussed here is about server-side statelessness. It allows you to build a server that gets all the needed information about a transaction from the data being provided (url, body, headers) rather than having to look up authentication information based on a token that the request carries. This is valuable when you want to keep your servers very scalable without relying on a shared data storage mechanism that they must all keep up to date with authentication tokens and data.
You seem to be agreeing that JWTs don't have state baked in, but can be tracked to the granularity you want, to adjust for your specific use case.
Also I'd be a proponent of tracking all the valid tokens if you care about invalidation, it gives more flexibility and you can report to your user their connected apps/devices.
On the general point, I think it's easier to add state and context to a system than to remove it, so I kinda agree with the tradeoff of having no state by default, even if for most public facing applications low granularity tracking will be needed.
We need our session tokens (Whether a random session ID or a JWT) to be able to be invalidated, which requires server-side state, but proponents of JWTs advertise statelessness as being a feature.
Granted, with JWTs, you'd only need to store a blacklist of invalidated tokens, whereas with plain session IDs, you need a database storing the data for every active session, so JWTs can still be used to minimize state.
You could easily put a session ID in it (and check against a DB), or have a field store a short expiration time stamp (and reissue periodically) if those matter to you.
Putting a session ID in it and checking against a DB defeats the supposed "stateless" benefit of JWTs.
Being able to use a current JWT to acquire a refreshed JWT doesn't prevent attackers from using stolen JWTs indefinitely. A short time stamp just means they have to catch the JWT live and not just steal it from some storage.
A ‘stateless’ JWT with a unique session identifier allows you to check state WHEN YOU WANT, but not when you don’t. So you can use it statelessly to your hearts content, or statefully when you need.
And the short time stamp definitely doesn’t mean an attacker can use it indefinitely, it means they can only use it for a short time before they have to check in with the backend that generates tokens to get a new one - which that backend would know that ‘logout’ or whatever had happened, and not generate one for it.
It sets a maximum period of time where old tokens can be used in a stateless fashion without ‘checking in’, while also not requiring a full synchronous check of a database on every usage of every token.
I think most folks would run away screaming from a codebase that did and did not check session data. Hopefully any company that does this has a lot of money set aside for bug bounties.
Every sizable system I’ve ever seen does it to some extent. It’s super common for static content with no security implications to not bother with a live check, or a system with high load but no major security implications (read only content for instance) to not do synchronous checks.
Especially if we’re talking 5-10 second session timeouts, it’s rarely even a theoretical concern and dramatically reduces load.
This is a bug, not a feature, especially if you make your tokens long-lived. If your implementation is completely stateless, then there's no way to invalidate a token to allow a user to log out. If a JWT somehow gets stolen, the user has no way to terminate the stolen session.
At best, you could create a blacklist of tokens that have been invalidated, which would delete rows as time goes on and the tokens reach their natural expiration date to avoid the database growing forever. But at that point, it's no longer stateless.