JWT is a token that is hard to forge with a payload.
Meaning, if someone gives you a valid JWT that says "I'm user 123" you can trust that this is user 123.
That's all it is. When reading in intent on how it should be used or what you should do with it, that's something beyond what the thing actually is.
So any pattern you can imagine with a session ID, you could implement with a JWT. Just throw the session ID in as part of the payload. Just because you are using JWTs doesn't mean that you don't have to work with any sort of external resource while you are processing it.
What purpose does it serve then? You can still avoid lookups when a JWT makes a claim. You know the JWT is valid so you know that all claims made within it are true. If it claims "I'm user 123" then they are user 123. If it claims "My account number is 435" then that's the account number. You don't have to make a lookup to see those facts are true. If it says "My session is 433" then you can validate that session 433 is still active and act accordingly.
JWT isn't a panacea but it also isn't anything more than a bag of claims. It doesn't claim to be anything else either.
> If it claims "My account number is 435" then that's the account number.
What if the account number changed since the token was created?
This works only for immutable claims. If the truth behind those claims changes in the mean time, you have to be able to invalidate the token, or accept the fact that it serves stale information.
> If the truth behind those claims changes in the mean time, you have to be able to invalidate the token, or accept the fact that it serves stale information.
Isn't that obvious? I mean, if we were talking about sessions and you put in the session set information that can change outside the session, wouldn't the same problem exist?
I just don't see this as a fundamentally unique problem for JWTs.
Meaning, if someone gives you a valid JWT that says "I'm user 123" you can trust that this is user 123.
That's all it is. When reading in intent on how it should be used or what you should do with it, that's something beyond what the thing actually is.
So any pattern you can imagine with a session ID, you could implement with a JWT. Just throw the session ID in as part of the payload. Just because you are using JWTs doesn't mean that you don't have to work with any sort of external resource while you are processing it.
What purpose does it serve then? You can still avoid lookups when a JWT makes a claim. You know the JWT is valid so you know that all claims made within it are true. If it claims "I'm user 123" then they are user 123. If it claims "My account number is 435" then that's the account number. You don't have to make a lookup to see those facts are true. If it says "My session is 433" then you can validate that session 433 is still active and act accordingly.
JWT isn't a panacea but it also isn't anything more than a bag of claims. It doesn't claim to be anything else either.