1. I think it's important to compare the security issues that JWT has had to the alternative. There, 'vanilla' cookie auth (which I assume to be session IDs) is

1. I think it's important to compare the security issues that JWT has had to the alternative. There, 'vanilla' cookie auth (which I assume to be session IDs) is by far the biggest offender. 2. It's not true that JWT is not stateless and therefore irrevocable. RFC7519 defines 'jti' for exactly this reason: > The "jti" (JWT ID) claim provides a unique identifier for the JWT. > The identifier value MUST be assigned in a manner that ensures that > there is a negligible probability that the same value will be > accidentally assigned to a different data object; if the application > uses multiple issuers, collisions MUST be prevented among values > produced by different issuers as well. The "jti" claim can be used > to prevent the JWT from being replayed. The "jti" value is a case- > sensitive string. Use of this claim is OPTIONAL. I think the rise of JWT stems from the fact that unlike traditional auth tokens (see the bundle of entropy legacy OAuth tokens were) they are human readable. When I set up an OAuth API that a user hits, I can exchange a short lived OIDC id token for a long lived capability based bearer for greater security -- and when developers use my API it's easy for them to tell why their capability token doesn't work without having to fire off a bunch of requests and guess. Edit: it occurs to me that the question of the JWT being 'stateless' might be about how session based storage often changes, but a JWT is largely immutable. Just for what it's worth, a session should not be revoked simply by removing it from the user cookie, or an attacker can persist simply by refusing to allow the cookie to be removed.