Hacker News Reader

Comment by ezekg | Hacker News Reader

I seriously don't understand the hype around JWT. They're useless to me since they can't be revoked. It's so much easier to just use a secure random token with an expiry. I could understand JWT at-scale to avoid hits to the DB, but none of us are likely at that scale.

View on HN

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.

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.

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.

Think of JWT as a lightweight SAML, to enable Authority A to vouch for User P's identity, roles, or other claims, in order to access a service (the "relying party") that trusts Authority A to do this, but does not itself maintain a way to authenticate or describe User P.

If you are both the security authority and the relying party then maybe JWT will not be useful.

A simple approach to revocation is using an ID + some kind of state maintenance (maybe redis) in conjunction with the token's "exp" attribute for easy TTL'ing of that extra state. This is probably no worse than CRL/OCSP features of PKI.

Reply on news.ycombinator.com