[frankthedog]

I believe GP is referring to user password not the encryption key. Rotating the encryption key would invalidate all previously minted JWTs. A user changing their password would not because it is not used to sign the JWT, therefore the old JWTs would still be valid until expiry after a user changes their password.

[bhandziuk]

It's my understanding that user's password + a server secret = the encryption key. Changing either one of those will invalidate the token.

[dns_snek]

Having to look up the dynamic signing key reintroduces a trip to the database. At that point it's nothing more than a session ID with extra steps.

[ehutch79]

Why in the fresh hells would you store a users password in plain text, in order to decrypt that key?

Even if you didn't you still need to retrieve the user and password from some storage to validate the key, which invalidates the reason for JWTs in the first place, since you supposed to be able to validate them without access to an auth service/db

[bhandziuk]

Plain text?? A user's password is hashed...You don't need a paint text password to compare text encrypted with it to other text encrypted in the same method. Either they match or they don't. The user's hashed password doesn't leave the server and plain text is never involved.

[b3morales]

If you use the password's hash as a key, the plain text no longer matters, because the hash is now the thing that an attacker needs to forge a credential. So your database is effectively storing the real password, as if you had not used a hash.

[bhandziuk]

I think I see what you're saying but how would that be useful still? Like is an attacker has a hash of the users password they still don't have the server secret.