Hacker News Reader

Comment by drinchev | Hacker News Reader

Biggest complaints about JWT is the inability to sign out a user. You can, yes, delete the cookie on the client side, but if the JWT is stolen you can’t be sure that it won’t be used again ( invalidate ).

Same happens on reset password, where by the book you need to sign out the user from every device. Good luck with that having standard JWT implementation.

View on HN

If your using a salt, just change the salt and deploy. We frequently do this and it works great. All existing tokens are expired.

So you invalidate all tokens? Or it is per user ID salt. If the latter where do you keep the salts and why not simply having a server side session ID, instead of the salt

If you have your tokens take more than an hour to expire, you're doing it wrong.

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