[davnicwil]

I think you have this right. This was also my experience with JWTs - go far enough down the revocation rabbit hole and it seems you just end up with a stateful solution again, but just with a more complex and expensive token verification mechanism (compared to just equality checking the token value). At that point, it really seems pointless.

[theprotocol]

>you just end up with a stateful solution again

It checks the "stateful" box in a nominal way, but it does not have the drawback of stateful session cookies that "stateless" defines itself in comparison to: in the backend, the session is still not in-memory or in-db on a single machine.

So you don't really go back to "stateful" except nominally; a very large part of the scaling benefit remains.

[davnicwil]

Let me be more concrete, maybe it will illustrate the point I'm trying to make better and/or highlight some aspects I'm wrong about.

I'm aware of broadly two schemes for revocation support with JWT:

1) Immediate revocation - keep a blacklist in state on a single machine. On verification of the JWT, check the blacklist and only succeed if it is not present.

2) Eventual revocation - keep a renewal token in state on a single machine, and give your JWTs an expiry time T. On verification of the JWT, if verification fails due to expiry then try to renew the JWT using the renewal token, and if successful then succeed the verification and also return the new JWT to the client. To revoke the JWT, just revoke the stateful renewal token. The JWTs can therefore be revoked eventually within a max time of T.

--

So, the above Vs the classical stateful session token (from here SST) approach:

Both 1) and 2) contain the same 'single stateful machine' limitation as SST, yet are more complex to understand, reason about and maintain.

In 1) you get no additional benefits over SST, and you have completely nullified the statelessness and therefore scalability of JWT. You also get the additional downside of a more computationally expensive token verification than just a simple equality check.

Conclusion - it seems irrational to use 1) over SST in all cases.

--

In 2) you get precisely one potential benefit for scalability - that for a time (max T) you get a stateless 'cache' for the verification of the JWT, which will horizontally scale to infinity. This MAY give you some practical benefit at massive scale, but there are two significant downsides:

A) You have a max lag T on revocation of the JWT, which is a security hole if the JWT is stolen. So you'd like to minimise T - but not so much that you lose the benefit of the 'cache' - otherwise the whole thing is pointless. You have to literally trade off security for scalability! Where do you draw that line?

B) The whole system is very much more complex to operate, debug, and reason about, than SST. You have verification logic that is split across 1 central stateful renewal token server & n JWT verification servers.

Conclusion - the scalability gain of 2) comes only as a trade off against security. Even assuming you are able to accept this trade off at all it is really unclear to what extent you should do so, and indeed if the whole complexity of the thing is even worth it after all that.

--

Perhaps there is another way to do revocation of JWTs that I've missed that is clearly superior to SST, maintaining stateless verification without any clear security trade offs. If so please educate me - I would love to discover it!

Otherwise, I concede that scheme 2) might be a better option than SST in some very rare and special cases, but in general if revocation is needed, then JWT does not make sense in place of SST.

[acjohnson55]

I'm using JWT for auth on a microservice so that it doesn't have to phone home to authorize requests. For revocation, the user service pushes the revocation to the microservice, which maintains its own blacklist. JWT works great for us because it contains all of the identity necessary for auth decisions on the microservice. An opaque token would require the microservice to phone home to get a user's identity data.

[theprotocol]

I appreciate the effort you put into writing your response. You make a very solid case and I wouldn't attempt to talk you out of using SSTs over JWTs given the level of consideration you've put into it.

I would nonetheless offer the following points if you'll excuse the rambling:

- I concede that the following probably exposes a lack of knowledge on my part. I think most, myself included, don't have a 100% lucid understanding of how session cookies are managed throughout the stack. It feels like there is some degree of idiosyncrasy and magic at every level, e.g. client -> reverse proxy -> application backend (-> potentially DB) while JWT feels much more lucid and consistent in this regard. It seems desirable and simpler to want to transparently pass through all the "smart" layers that have explicit knowledge of and opinions about session cookies.

- JWTs come off less "magical" than session cookies and I find them just as easy, if not easier to reason about in certain situations, e.g. in an app rather than in a browser - I'm aware that cookies are mere headers, but I still find that slightly more annoying to manage than JWTs - although I concede that perhaps this is merely due to the availability of libraries that make it so, while also not being too "magical" and hiding key parts of the flow (whereas various platforms e.g. ASP.NET, PHP do weird magical things with session cookies).

But, you know, your post is making me have second thoughts about my position here, and I may yet be won over after thinking about this some more. I think this is often an underrated and unnoticed point - that there is some a priori magicalness about session state, while JWT is simply presented less magically, and so one may be attracted to the initial lucidity of JWTs vs. having to learn session state (because "why haven't I learned how automatic session management works after using it for all these years? It's probably very hard"). And I'm beginning to realize choosing JWTs for this reason may be specious.

- I find, in practice, that a JWT workflow's blacklists are still a lighter level of statefulness than having to propagate user sessions. As you rightly state, this comes in the form of eventualness, and it is indeed a security tradeoff. Here, perhaps my imagination (or experience) is lacking, but I estimate that it would in practice be difficult using SST for 1. To have a token theft; 2. To detect said token theft; 3. To implement security measures; in less than the time of JWT revocation.

- I obviously find that JWTs make more sense than session cookies in RESTish APIs, in which the desired workflow is modeled after HTTP and does not require a session on the backend (so the statelessness is not just for scaling). It's certainly a good thing to have a standard for passing a verifiable proof of authentication inline with every request.