I mean, this isn't really true though. If you forgot, you can have your JWT middleware check and if the field is missing, revoke it. There are tons of workarounds here and I have implemented them in several consulting roles. I personally always put a created and expires timestamp, bit if they aren't there, there are ways to fix the situation easily.

Hmm, couldn't you also rotate encryption keys once a day/week, and keep the last one or two available, and if decrypting with the current one fails, try a prior one? Eventually, that token will no longer be readable. It should only ever matter in the weird case where your expire time is screwy, but you've put a bound on how long a token can survive no matter what.

No, not period. If you're using an API gateway (which you should be), you can check against blacklisted tokens. The `jti` is your unique token identifier. As long as you have a way of maintaining a blacklist of tokens, this is trivial.

One of the major points for signed tokens is stateless operation. If you need to maintain a blacklist, you lose that, and the question arises: why not just have a whitelist of tokens/UUIDs/... to begin with?

This is why people suggest "short tokens" as a work-around, accepting a 5min window of unrevokable tokens as trade-off.

Or, one has to justify that a blacklist implementation is significantly cheaper than a whitelist one. But is it, really?

If you have a sole identity provider, or token issuer, the blacklist can be quite simple to maintain. Plus, with short token life spans, you probably aren't revoking tokens very frequently.

In my experience, usage of the black list occurred with two use cases:

1) Invalidating all of a user's tokens 2) Alteration of claims that a user's JWT should have

As far as your applications go, you still have the benefit of not having to bother with checking the state (this is already done by the gateway).

That depends on the size of your system. I've worked on systems with so many servers that it would be cripplingly difficult to quickly propagate all whitelist updates to all servers in all services that would need to verify against the whitelist, and the alternative of doing a lookup against the whitelist for every request would be extremely expensive.

On the other hand, you generally expect that you rarely ever need to actually revoke tokens, so you can naturally expect that a blacklist will change infrequently and will remain tiny compared to the whitelist.

As the size of the service grows, most people converge to a fast train/slow train design: the whitelist is big and is accessed infrequently, and the blacklist is tiny (goes obsolete within the TTL of the whitelist query) and can be pushed out quickly.

If you're one of the tech giants, it's not slightly cheaper, it's a lot cheaper.

Or more simply, just check that the JWT has an expiry date, and it's a "sane" one - you can do both these checks without requiring a blacklist.

yep. however, the token is then not "stateless" anymore since you have to take note of the blacklisted state.

however, once you really care about the security perimeter, i think the requirement/wish "stateless" must be dropped.

You can add this type of thing to your validation code: exp has to be set, can't be in the past, and can be no more than x time in the future (where x is somewhere between what you're actually signing now and the largest value you could ever conseivably want to use without having to push an update to this app).

One of the biggest challenges with using JWTs is really all these gotchas that you have to think about. This isn't dissimilar to the infamous `alg:none` fiasco. In this case, it's not really about protecting against an attack, but forcing the developer on the other end to think about it. Their quick initial code that doesn't bother setting exp or has it hard-coded to 1000 years in the future will never work, so it had less chance of being left in to cause a security issue later.

All such tokens would be effectively revoked anyway since you check the iat timestamp (or lack thereof) at the authorization point.

Yep, and that is what we do. But we also check to ensure that a secure cipher was used, not none. Many of the "JWT is insecure" type articles (and real vulnerabilities found) were based on the fact that people just used dumb defaults and didn't secure things. So the argument is really that JWT is a footgun without some adult supervision.

When verifying the token you could just check if exp is set and if the lifetime of the token does not exceed your limit.