5 ms·
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
by ezekg 10y ago
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.
- wedowhatwedo 10y agoThey 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.
- michaelchisari 10y agoWhat 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?
- Posibyte 10y agoWe 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.
- ves 10y agoYou 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.
- politician 10y agoExactly, the database solution is overkill for tokens that are revoked prior to their expiration.
- rhinoceraptor 10y agoYou also just do it in Varnish/Nginx/etc and stick that in front of the application server entirely.
- ezekg 10y agoThat'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.
- deathanatos 10y agoYou 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.
- ademarre 10y agoIn 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.
- pjwal 10y agoThis 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.
- sk5t 10y agoThink 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.