Don't use JWT: https://fly.io/blog/api-tokens-a-tedious-survey/ (by @tptacek)
Like any tool, JWT can be misused and you can do insecure things with it. I actually quote @tptacek in a different article about JWTs: https://fusionauth.io/learn/expert-advice/tokens/building-a-...
However, JWTs have strengths too. They are:
* flexible
* widely supported
* standardized
* stateless
* portable
* relatively easy to understand
* extendable
Edit: fixed typo (relative -> relatively).
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.
They are presented to the AS to get a new access token, and the AS has pretty good insight into whether a user is logged in or signed out, right?
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?
About the same amount of effort from my perspective, and revokes are probably extremely rare by comparison to issues or validations of tokens/sessions...
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 jwt being valid 10 minutes (accounting for clock drift) might be a problem - but probably sufficient for many applications?
Isn't that what you want ?
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.
It just isn’t REQUIRED.
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.
Especially if we’re talking 5-10 second session timeouts, it’s rarely even a theoretical concern and dramatically reduces load.
Other than that, it seems nice. A better JWT than JWT with some of the sharp edges removed.
I've actually filed an issue for our product to support PASETO and it's gotten some community support, but not an overwhelming amount.
There are downsides for almost everything out there. Outright dismissing JWTs is not correct.
In either case, you can suggest "let's use <X> token" where X is paseto or something else, but you can't dictate it (Google certainly won't listen and change formats :) ).
I see so many cases where someone asks "what should I use for auth" and immediately the answer given is JWT, where simple random tokens or session auth would be just fine. And simpler to implement, since they're supported out-of-the box in many frameworks.
I think one of the reasons JWTs come up so often is that if you are going to use OAuth2/OpenID Connect - ideally the Authorization Code grant, then tokens become an important component.
And many IdPs implement the OAuth2 access token as a JWT. So it may be that your IdP ends up making this choice for you. Then you have to learn how to deal with JWTs.
My main takeaway from it that JWTs aren't magical, there's exploit vectors that need to be taken into account, and as any security related thing, you need to do your homework to have a decently secured application.
That's pretty far from "don't use JWT"
> This is a problem because the ability to read your user profile isn’t a good identity proof. You might grant that capability to applications for reasons having nothing to do with whether they can “log in with Twitter” to a dating app. People found a bunch of vulnerabilities.
> Enter OpenID Connect (OIDC). OIDC is the demon marriage of OAuth 2.0 and a cryptographic token standard called JWT. OIDC’s is unambiguous: it gives you an “Identity Token”, JWT-encoded, that tells you who’s logging in.
Ah, so it’s more of a case “don’t use jwt… incorrectly“.
I also recommended looking at UMA2 and resource servers. Keycloak has, what I’d call, my to go reference implementation.