[zdragnar]

You can use a separate DB that acts more like a cache for revocations- usually something where you can set a time to live on the row equal to the duration of the token itself.

That keeps your application DB free for application load, while keeping your identity validation logic nice and snappy.

Of course, adding infrastructure may be intimidating, but most applications that face any real load are going to be using redis or something similar anyway at some place in the stack.

[akerl_]

If I have to run a separate DB to check for revocations, why not skip JWTs and just use that separate DB for auth directly.

[andoando]

Not an issue for most cases but a cache of revoked tokens is going to be much smaller than a db of all users tokens.

[zdragnar]

The advantage of redis or similar kv DBs / caches comes in being lighter and faster than a full second database, mostly.

The secondary advantage is you don't need to deal with cookie storage, sticky sessions or anything else along those lines.

If you're manually hand crafting a server, go for it. If you're treating them like cattle not pets, going stateless with a bearer token tends to be easier.