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.

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

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.

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

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.

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.

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.

The users password isnt involved with the encryption of JWTs

If the user's password isn't involved then what's the mechanism for invalidating existing tokens?

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.

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)

There is none. Personally, I use it for authentication on a platform where the user shall be logged out after 30 min anyway.

What? Why whould the signaure be invalidated?

Not the cryptographic signature; they mean the authorization.

I.e. if the user's password has been compromised, then the attacker with the password could have started a new session using it. The question is, how do you (allow the user to) revoke the auth that was granted by the compromised password and invalidate that fraudulent session.