Hacker News Reader

Refreshing a specific token can not be blocked on the server side. If you do, it’s already stateful.

I am of the anti-JWT crowd, so I completely agree, but this would still only hit a "login service" which would know if a new JWT could be given to this token.

Still, an hour is a LONG TIME when a session could just kill all requests immediately for a user.

If that's the case, then why refresh? Might as well just hand out forever tokens, which, you're right, makes less than zero sense.

The point is that you have two tokens, one a refresh token and one a stateless token. You revoke the refresh token on the server, which means the next refresh attempt will fail.

Then why not just use "refresh token" as a session token?

Because it's stored and that would require a round trip to your auth server on every request. Plus, its security requirements are far higher than the access token, so you don't want to be flinging it all over the internet. It only ever goes between your users and your auth server.

Reply on news.ycombinator.com