3 ms·
> I have trouble understanding why session invalidation with JWT's is challenging. Imagine you're connecting to a service that uses JWT for sessions so they do
by CiPHPerCoder 8y ago
> I have trouble understanding why session invalidation with JWT's is challenging.
Imagine you're connecting to a service that uses JWT for sessions so they don't have to store anything server-side.
Let's say you have a token with an IAT of yesterday and and EXP of, say, a month from now.
Further, your browser gets infected with malware and the attacker steals your token. You rebuild your computer from a fresh install.
How does the service invalidate the token while still being stateless? It has 30 days left.
Your next move is:
> _
- jrs95 8y agoYou should have tokens with short durations that are refreshed upon use. That greatly reduces the odds of a token being stolen or leaked and then used before it expires.
- CiPHPerCoder 8y agoYou're getting closer to the problem: JWTs were designed to be single-use (or very, very short lived) claims (with optional cryptography features). It was never meant to be "offload everything to the client and obviate the need for server-side storage". It was never meant to be the new hotness among the NoSQL Scalability crowd.