Hacker News Reader

Comment by wedowhatwedo | Hacker News Reader

They can be revoked. Our JWTs have an ID in them. We have a revoked table. If the ID is in the revoked table, the JWT is invalid. It requires a DB hit but it is worth it for the ability to revoke them.

View on HN

That's my whole point. If you're doing that, you might as well not use JWTs seeing as that defeats the entire purpose of using a stateless token that doesn't require DB hits.

You can cache the table — which is usually empty — in the places where you need to validate a token to not require the DB lookup. You can also push changes in the revocation list to those places as well. Or, you can just have the DB lookup, but then cache it for 5 or 10 minutes: revocation will take that long to take effect, but most authentication verifications will still be very cheap and not require a lookup.

JWTs allow it to be stateless, or some tradeoff along it appropriate to your needs. Having the client pass an ID to a database row means you can never get that behavior, as you always need to look up that row from the DB.

In addition to single token revocation, you can use the account epoch approach (at least that's what I call it):

Store an "epoch" date in the database for each account. Tokens issued for that subject are considered invalid if they were issued before the epoch. This allows you to do mass token revocation (e.g. sign out all active sessions) without knowing the IDs of the tokens that have been issued.

This is the approach I take. The subject should always be queried, so just use a field on that subject for the purpose of killing current sessions.

What advantage does this have over a session token/table? If you have to hit the db every time the JWT is referred to for an operation in order to prevent post-revocation activity, what advantage does the JWT provide?

We keep our ID blacklist in something like Redis. For how rarely we need to add clients to it, the switch to simple-state JWTs has made noticeable improvements to the speed of our API, especially during higher usage times where our Postgres DB bogs down a bit.

So I'd say the advantage really varies by where you're coming from.

You could even switch what you have in redis to a bloom filter if the space of revocation tokens gets large (which it shouldn't).

You don't need to support a database online if you're just checking for membership in a small finite set.

Exactly, the database solution is overkill for tokens that are revoked prior to their expiration.

You also just do it in Varnish/Nginx/etc and stick that in front of the application server entirely.

Reply on news.ycombinator.com