4 ms·

The users password isnt involved with the encryption of JWTs

• bhandziuk 4y ago
  If the user's password isn't involved then what's the mechanism for invalidating existing tokens?
  • super256 4y ago
    There is none. Personally, I use it for authentication on a platform where the user shall be logged out after 30 min anyway.
  • ffo 4y ago
    One could include the SID claim, with this the token at least could be tested against a users session on the IdP/OP. (This is being used in the ID_Token in OIDC)
  • Sohcahtoa82 4y ago
    There is none. And now you're starting to understand why JWT's aren't worthy of the hype. A truly stateless JWT implementation is insecure since you can't invalidate existing tokens. The usual compromise is make JWTs have a short (<= 15 min) expiration and provide the client with a refresh token that doesn't expire, but is stored server-side. When the user logs out, the refresh token is invalidated server-side so a new JWT can't be issued. You're re-introducing state with this solution, but you're making it so you don't have to bang on a database with EVERY request, just one every ~15 min or whatever your expiration window is.