Comment by zbjornson | Hacker News Reader

Comment by zbjornson | Hacker News Reader

We naively started with JWT for auth, and gleefully ripped it out after several months because of all of its cons.

1. Overall, no net benefit. We still had to query a k/v store on every action to check that the token wasn't revoked.

2. Less secure because there's no way to make it act like an HTTP-only cookie (no access from JS).

3. No way to revoke all of one user's tokens because there is no list of those tokens. We want to limit (or be aware of) the number of active logins and let the user sign out from all locations (as you can in Gmail). If the token is only stored on the client, there's no way to do this. You could store a list of all granted tokens and only use it for these revocations, but that's yet another level of complexity. (When we dropped JWT, the diff was -1200+95 LOC because we had to handle a lot of scenarios like this.)

4. Adding tokens to client-side requests is a pain. The common example for e.g. Angular is to use an HTTP interceptor to add a header. More code, but it works... Except for img and a (anchor/link) elements where you can't add a header. So you put the token in the URL query instead, and now you're vulnerable to session leaking if a user shares a URL with someone else. And you have to manually update those embedded tokens when they expire, as many JWT folks recommend you make the expiry short.

Good riddance.

Yep. Revocation is tricky with JWT, but it's not that bad.

The expectation should be reduce in database io, not getting rid of it entirely.

Overall you could issue tokens with short lifespan, say 5 minutes. And having the client refreshing tokens periodically. Reading database every 5 min is certainly an improvement over reading it on every API call. You could also only check revocation table if the performed operation is security-critical or sensitive enough. I wouldn't care if the user is trying to perform a read-only operation on some public data with a revoked token that is going to expire in a few minutes anyway.

>3. No way to revoke all of one user's tokens because there is no list of those tokens

I don't see why one would not maintain such a list, since generally issuing a token requires database io anyway. Storing a token when issued is just one additional write op.

We decided to use JWT internally, and force clients through an API gateway that converts between a classical session key (stored in a fast, distributed key/value store) and an internal JWT.

This means that internal microservices don't need to deal with session management at all (including revocation), and only need to worry about validating the public key of the signer.

Yet if anything is accidentally exposed (let's say a microservices fetches a user-provided URL, and the URL is localhost), the user still cannot spoof an identity without having the signer's private key.

The internal JWT also has a very short TTL, so accidental leakage wouldn't cause much trouble.

I would not use JWT for session management.

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

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