|
|
|
|
|
|
by cogman10
1362 days ago
|
|
|
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. |
|
|
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.