Hacker News Reader

Comment by TomMarius | Hacker News Reader

One benefit over simple token formats (e.g. using UUIDs as tokens) is that you are able to quickly invalidate the token, because you don't need to hit the database at all.

Second benefit is, at least for me, standardization.

Edit: fixed typo

View on HN

How do you invalidate a JWT without hitting the database though? The JWT is already signed with its claims, so there's no way your application can know it's revoked unless there's a list of revoked tokens, which defeats the whole purpose of using JWT. Or am I missing something?

You are not missing something. We're both in the same boat looking for this island of treasure.

No, no, you got me wrong. The point is in faster invalidation, not validation. That means you are immediately able to tell an invalid token from a not-yet-determined one (but not from a valid one). Then you have to hit the database, but the number of hits is - in some cases drastically - reduced.

It sounds like you mean if you change the signature used to sign the tokens, then existing tokens will fail validation without hitting the db? If so, that's not too practical because all of your users are suddenly signed out. What myself and the two other posters I think encountered is that you have to store revoked/invalidated tokens in a blacklist, and then check that a token in a request is not in that blacklist. (That was my first point, at least.)

No, I simply meant that instead of checking if a token is valid, you can first check if a token is obviously invalid (e.g. expired, wrong claims, wrong audience...), and immediately return if so, thus reducing the load on your application servers and databases; and only then query the database to check if the token has been revoked.

You can build a bloom filter on schedule which will tell you definitely if the token has not been revoked without hitting the database.

Reply on news.ycombinator.com