5 ms·
We have a requirement that users be logged out after 30 minutes of inactivity, so JWTs are perfect for our use case.
by csours 8y ago
We have a requirement that users be logged out after 30 minutes of inactivity, so JWTs are perfect for our use case.
- drinchev 8y agoWhat about a stolen user password and an actor, who already uses your token? Can the targeted user kick him out by resetting his / her password?
- nbevans 8y agoSure why not? Each user account has a counter or timestamp on it in the user registry. If the JWT token in the request passes crypto validation but it has an older counter/timestamp than held in the user registry then it is deemed invalid and the user must re-authenticate. This is still a horizontally scalable design.
- gravypod 8y agoThen you are back to statefulness if you need to check this magic "count" every request.
- nbevans 8y agoYou can horizontally scale counters with CRDTs, specifically the G-Counter. Whereas it is harder to scale a (usually) opaque blob of application state a.k.a. session state.
- aaaaaaaaaab 8y agoThis “user registry” of yours sounds an awful lot like a traditional session table in a central DB. Could you elaborate a bit on that in terms of horizontal scalability please?
- nbevans 8y agoUser registry can scaled however you want it to be. It is simply the service that manages user accounts, passwords, permissions, and of course issues the JWT tokens. Equally it can be a horizontally scaled micro service.
- csours 8y agoNo, but that's 3 systems away upstream anyway - thus the 30 minute timeout.
- jt3 8y agoUsers may wish to log out sooner than 30 minutes too.
- scient 8y agoExcept cookies are quite literally perfect for that - set the expiration to 30 minutes from issuance and it will automatically be expired with inactivity. Or bumped on activity.
- deathanatos 8y agoYou shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.) (Now, if you mean looking up a session token in a database and checking that for expiry, then yes, that works, but the only real difference between JWT and tokens then is the latter requiring a database query.)
- yen223 8y agoThe more important difference between JWT and tokens is that the former requires you to trust that your encryption mechanism is foolproof, whereas the latter doesn't.
- deathanatos 8y agoSession tokens (an unguessable identifier that identifies server-side stored session data), while they don't need to be encrypted or signed, the identifier should usually be cryptographically random, however, so you can still get into trouble there. JWTs don't have to be encrypted. (And IME, typically aren't.) They need to be signed, but the algorithms that do this are common, well-understood algorithms. Some of them are likely being used by TLS to protect your session anyways. If they're not foolproof, you have bigger issues than JWT. If you are referring to the implementation, then sure, but the same concerns exist about your implementation of TLS, and the same advice applies: use a well-known, hopefully well tested library.
- nbevans 8y agoCookies are implementation dependent. It's quite possible that a user agent doesn't honour what you instructed it to do regarding the expiration of a cookie. JWT however... your server side can validate its own token in whatever ways it wants (including expiration). You can't get more secure than that.