Hacker News Reader

Comment by 2-m3m3n70 | Hacker News Reader

So thoughts on an actual solution? Invalidating tokens means you have to maintain an infinite growing list of invalidated tokens and perform a lookup on every login - somewhat defeating the purpose of 'stateless' tokens like JWTs (ie why not just implement a traditional session store then).

Furthermore, if sniping someone's token like this was doable over MITM, what's to prevent someone from grabbing a live token and then infinitely refreshing it (provided there's a /refresh endpoint).

I'm really wondering if anyone has best practices around this because I have not seen anything.

View on HN

Good point. I wonder if it is sensible to limit the number of refreshes permitted (by placing a counter in the JWT that gets decreased on every refresh). That way you could have the JWT be valid for, say, 30 minutes, and allow up to seven refreshes; after four hours you would have to re-authenticate.

As for invalidating tokens; if tokens expire after a sensible interval (as they should), than you would only have to maintain a short list of recently issued and invalidated tokens. Older tokens can be removed from that list, because they cannot be used in any case after expiring. You could use a cache with a TTL set to a bit over the configured expiration interval.

The problem is that having a counter doesn't really work, because you can't force the client to take the updated JWT. (And the previous JWT is still valid as it's checked based on signature.)

The way to go is pretty simple - issue a long-term refresh token, and a very short-term JWT to the client (as little as 5 mins or so). The app can then make requests directly to the services, which can independently verify the validity of the JWT.

The services then also check for tokens which have been revoked - using a very fast mechanism, like holding them in-memory or querying a Redis store. The token's JTI only needs to be held in the revocation list for a short period of time - until the JWT expiry time - using a TTL in Redis, or similar.

The app uses the refresh token to get replacement JWTs. It goes with the refresh token directly to the auth service, which can then check whether the user should be able to get new tokens or not.

When you use JWT with the option to refresh the tokens, you usually set an expiry date on the token (if not, there is no point in refreshing at all). So in order to stay authenticated, the client application has to refresh the token a short while before it actually expires and use the new one (which has an updated expiry date) or simply get signed off.

The previous token expires automatically — a well-designed back-end checks against the expiry date and any other claims that should be verified, as well as the signature. So you can force clients to accept the new token with a counter that gets decremented at each refresh until you have to re-authenticate.

There is no need for a separate long-term refresh token.

Reply on news.ycombinator.com