You can implement a blocklist of all the revoked JWT and publish it to all servers. The list should be small, because only otherwise valid tokens need to be included. It becomes so much more complicated than a simple check-the-db setup though.
I don't think I would start with JWT if I did this again.
You're talking about tokens in general, not just JWT. The only alternative I know to tokens is to query the DB every time (or perhaps use a cache to make the lookup less often, but then you also have to find a way to invalidate the cache - back to square one?).
> You're talking about tokens in general, not just JWT.
Yes, all stateless tokens. But I have never seen an in-house token system that was not using JWT's.
Yes, query the DB or some sort of storage every time. It sounded so clean and nice and fast to just check JWTs without any network calls. But it ended up very messy and complicated. Might still be worth it in some cases, of course, but I would start my next project with random sessions stored in a db or redis or memcache or .. something :)
You can actually do crazy stuff with your sessions as well, to avoid a normal db lookup. But in practice all services I have worked on would/did not suffer noticeably for a fast DB lookup.
Having to list the tokens to revoke is a problem in several ways. Obviously publishing the tokens themselves allows attackers to use them before relying parties get the revocation notice, so publish a token hash instead. But even publishing a token hash is annoying because you then have to record all the claims + token hashes issued, and that's a failure point. Instead you'd want to revoke _subjects_ (`sub`), but since tokens don't have to have those... (In enterprise systems though your tokens should name subjects.)
I don't think I would start with JWT if I did this again.