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.