4 ms·
I have trouble understanding why session invalidation with JWT's is challenging. The JWT itself contains an IAT (issued at time) describing when the token was
by sgslo 8y ago
I have trouble understanding why session invalidation with JWT's is challenging. The JWT itself contains an IAT (issued at time) describing when the token was created. To invalidate all sessions, you can store (in your DB, or other persistence service) a 'invalidated at' date. Any request with a JWT that was issued before this 'invalidated at' date can be considered to be invalid.
- 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.
- hobls 8y agoSure, but then you’re calling your DB to validate the JWT every time anyway. You’ve just removed the whole “JWTs are cool because they’re stateless” benefit.
- draw_down 8y agoYeah. Turns out the world has state. Bummer!
- deleted 8y ago[deleted]
- quaunaut 8y agoBut that's just it- only for all tokens. What if a user changes their password? Until that token hits its timing limit, they've got free reign. Or, you use denylists, requiring the database again.
- mikeryan 8y agoI’ve gotten used to using the Amazon style of using an accessToken and refreshToken. The accessToken expires in 5 minutes and the refresh is used to get a new access token. So at most you have a 5 minute window of acesss. More boilerplate Code and bandwidth but it works fine. My issue with the article is that we’ve generally stopped building our own auth and now lean into using cognito or auth0 for authentication for the sites we build for third parties. Those services provide so much more out of the box then a home rolled solutions (MFA etc).
- jpalomaki 8y agoThe problem with blacklisting is that then you end up doing the database hits and avoiding those was one of the reasons for adopting signed tokens. I see the value of signed tokens in complex infrastructure where you want to have one heavily guarded system doing the authentication and token assignment and then a bunch of other systems just validating the tokens.