3 ms·

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

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.

pkulak 8y ago
If you have your tokens take more than an hour to expire, you're doing it wrong.
- drinchev 8y ago
  Refreshing a specific token can not be blocked on the server side. If you do, it’s already stateful.
  - pkulak 8y ago
    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.
    - ortekk 8y ago
      Then why not just use "refresh token" as a session token?
      - pkulak 8y ago
        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.
  - 0xCMP 8y ago
    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.
sudovoodoo 8y ago
If your using a salt, just change the salt and deploy. We frequently do this and it works great. All existing tokens are expired.
- drinchev 8y ago
  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

pkulak 8y ago

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

drinchev 8y ago
Refreshing a specific token can not be blocked on the server side. If you do, it’s already stateful.
- pkulak 8y ago
  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.
  - ortekk 8y ago
    Then why not just use "refresh token" as a session token?
    - pkulak 8y ago
      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.
- 0xCMP 8y ago
  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.

sudovoodoo 8y ago

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

drinchev 8y ago
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