3 ms·
On a project I worked on, we implemented a "log out all devices" option and similar security features by building a simple deadline system on top of using JWTs.
by cybrox 3y ago
On a project I worked on, we implemented a "log out all devices" option and similar security features by building a simple deadline system on top of using JWTs.
Every user's data contained among other things a deadline timestamp, which was (re)set every time a security relevant data point was changed (password, 2FA, log out all devices, etc...)
When authenticating a user, services would check for both the JWTs validity (iat, nbf, exp), as well as the cached deadline (iat >= deadline) using a shared auth library. I'd be happy to learn more about the downsides but for as long as this was in place, it has worked really well.
- Zetice 3y agoThe whole point of JWTs is to not check some other value in the backend. Once you're doing that you've lost the major value of JWTs. So yeah, once you start doing DB calls for every. single. request. you're going to have a lot more options, but JWTs are meant to avoid that. My understanding is the "right" way to do this is to maintain a CRL.
- michaelsalim 3y agoWhat is CRL supposed to stand for? Google only gave me "Certificate revocation list" which doesn't sound right.
- AntonCTO 3y agoYes, it is good if you can avoid checks, and in most cases you can. But in practice it doesn't matter very much: - Scaling is rarely the problem. I never experienced it myself. The same goes for the session. - The complexity can be hidden behind a library. Iirc there is even a specification for this. - You have other advantages because you usually use JWT with OAuth2.x/OIDC in the SSO context. - You benefit from standardization. CRL is probably not going to help you. At least I have no idea. But jti's blacklist will. Don't forget - you still have to maintain and distribute it, which probably won't lead to a better implementation.
- preseinger 3y agoscaling auth infra is basically the entire motivation for things like JWTs if you don't care about every request making an auth check, that's great! then just use basic sessions or whatever. there's no reason to use anything more complex
- febusravenga 3y agoAnd what parent post described is functionally equivalent to CRL it's a list of user (id, earliestValidTokenTimestamp) which for case of invalidating all sessions on demand serves same purpose. The only major problem is timely sync of those lists in all clients. Same problem as with CRLs, but probably lighter. And of course with other set of limitations.
- cybrox 3y agoNo, you have lost ONE of the major values of JWTs. You still enjoy a lot of the others (standardized data structure decodable by both sides, library support, easy custom payload). Also, DB calls are not necessary, when it comes to scaling, in-memory caching is a very valid option, so a DB read is only necessary occasionally. Yes, you lose some of the benefits of JWT but that's inherently expected when using them for something that goes beyond their original capability.
- preseinger 3y agothe only unique advantage of JWT-type auth is reducing load on auth backends everything else you mention is equally available in other, simpler, auth schemes
- cybrox 3y agoYes, I didn't disagree with that. All I'm saying if you're already using JWTs, you're not locked out completely from implementing these features. It just comes with a drawback that might be worth it, depending on your customerbase and team size.