By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to.
JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation system. But at that point you're back to square one and the architect working on this should consider why they're undoing the legitimate benefits JWT provides.
Nonce based revocation is an active process. Timestamp expiry is not actually revocation, it's expiry. If your token is compromised prior to expiry, you're out of luck.
> By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation.
That's patently false.
JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes.
The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens.
> JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control.
This sort of argument is ivory tower nitpicking stated disingenuously. JWT include issue and revocation timestamps, which already renders the workflow stateless. The only stateful aspect, which is silly nitpicking and technically irrelevant, is keeping track of nonces and arbitrarily revoked tokens, which require keeping a database to track revocations.
We’ve been going back and forth like this for quite a while, so at this point I doubt I’ll be able to convince you with further explanation. I’m shocked you think it’s “ivory tower nitpicking stated disingenuously” to call stateful tracking of nonces what it is - “stateful.”
I’ll recuse myself from further “nitpicking” I suppose, because this isn’t going anywhere. If you’re interested in actually following why your suggestions are a poor fit for session authentication, I’ll direct you to this flowchart: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-....
That's just an argument ignoring the realities of scale. In any reasonable system the number of tokens that need to be held in blacklist until seen will be tiny in comparison to active sessions.
How does it matter how many tokens are in the blacklist? You're looking them up in a DB where the lookup time in lg(n) anyway. To give you an idea of how little it matters, let's say a small blacklist would be 10k tokens while a list of all tokens would 10M. log(10k) = 13.28. log(10M) = 23.25. It's only marginally more, because the main latency of the DB request is the network round-trip time.
The actual issue here is that a lookup needs to be performed at all. For every request, you need to pay the latency of one DB round-trip as well as maintaining code that does this lookup. And if you're going to do that anyway, why bother with this complexity of "stateless" tokens?
How does it matter how many tokens are in the blacklist?
If you're authentication something internal to a company, like the link between the website and the order status backend, there may be literally one user with one token.
In this case, the list of revoked tokens will take little space, and update very rarely!
If you're authenticating users logging into your website and you decide user logouts should be implemented by token revocation, you're going to have a great many revoked tokens - perhaps within an order of magnitude of the number of active users you have.
I suspect a lot of the disagreement here is between people who are thinking of different situations.
What you’re describing - a microservice architecture - is actually a legitimate use case for JWT. I would say that’s an example of sound authentication, but it’s not session authentication, which is what’s being talked about here. Microservices authenticating and communicating with one another don’t utilize the concept of sessions in the sense that clients (users) and servers do.
For that reason I don’t know that it’s fair to say the disagreement throughout this thread is due to people talking about different things. Microservice authentication notwithstanding, session management is not optimally handled by JWT.
I think the answer is supposed to be that you've done your architecture wrong if you ever allow a revoke list to grow as high as 10k or beyond. You should not have to grant very many long-lived JWT tokens to begin with, so for most revocations it should always be enough to simply let them expire.
If the token blacklist is budgeted and never allowed to grow to a size of more than say 10-200, then it can probably be safely maintained over the lifetime of the project in a way that doesn't require a round-trip, in the source code for the service or otherwise gated behind a release barrier.
I don't know if I agree with that (I've never implemented JWT) but at least I think I've heard of the idea that's how the architecture is supposed to be planned for JWTs.
> If you have to track revoked tokens you might as well track active sessions via a session ID.
No. Tracking revoked tokens is only necessary if for some reason a server wants to reject a valid token, and that's only required until the token expires.
The use of nonces to avoid replay attacks is also a widely established practice, thus we're not talking about extra infrastructure.
Tracking revoked tokens also doesn't take up any resources as tokens are designed to be short-lived.
JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation system. But at that point you're back to square one and the architect working on this should consider why they're undoing the legitimate benefits JWT provides.
Nonce based revocation is an active process. Timestamp expiry is not actually revocation, it's expiry. If your token is compromised prior to expiry, you're out of luck.