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.
