[wokwokwok]

> A problem is that a user can't revoke a JWT.

Bluntly, this.

If you need need this functionality, for example, when you log out of a banking app... and if you've implemented token revocation, eg. by storing a list of 'revoked' tokens in a database somewhere when someone 'logs out' or gets banned.

...then, in most cases you should not be using JWT.

Once you make your JWT stateful, by storing it in a database there is no reason to use JWT.

...and since that is the only way to implement that functionality using JWT, there are many times when JWT is not a suitable choice.

[acaloiar]

> Once you make your JWT stateful, by storing it in a database there is no reason to use JWT.

JWTs are a cryptographically sound means of conveying identity between systems, assuming the implementation doesn't allow `algorithm: none`. I'm genuinely curious why you perceive JWTs as useless when they're stateful. It's a common opinion, so I assume there's something to it. My best guess is that it stems from JWTs being "sold" as a stateless means of conveying identity. In which case, I think they fall short of that promise. I just don't equate that with useless. I'm using the word useless, which I interpreted your statement "no reason to use JWT" to mean, but feel free to correct me on that.

[EE84M3i]

I guess it depends on how fast revoked sessions need to stop working and how many you have.

If eventual consistency is good enough, presumably you could use something that looks like a bloom filter of revoked tokens and only check ones that match against the revocation service, right?

[geraldwhen]

This is exactly how many banks handle auth because 1.) jwt is mandated and 2.) so is session revocation.