4 ms·
Your architecture being microservices doesn't change the problems with using JWTs (or any "session" system based on signing things): you can't revoke them. I a
by ZoFreX 10y ago
Your architecture being microservices doesn't change the problems with using JWTs (or any "session" system based on signing things): you can't revoke them.
I am pretty confident being unable to revoke tokens will start to be a problem with any sufficiently large websites: you don't just need to scale in terms of traffic, but also in terms of people doing bad things.
If you're at this sort of scale, adding in another service that validates sessions is not a lot of work. Either your microservices that need authentication could have a library added to talk to this service, or you could put everything that needs auth behind something that validates the requests as they come in. Vulcand looks like it makes this easy (I haven't used it personally, but I've worked on a system that works similarly using an F5 device).
Sooner or later, you _will_ regret not being able to revoke sessions.
- numbsafari 10y agoYou can (and should) use a revocation list. This is really no different than doing invalidation/revocation of stored sessions because you have the same job of sending the session/token ID out to all dependencies. But, instead of keeping a giant memory store of all sessions in sync across clusters, you only have to keep a short lived list of revoked tokens. Less noise, less memory, same difference.
- ZoFreX 10y agoSay an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them. Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier?
- wtbob 10y ago> Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them. The revocation list could include entries of the form (revoke-all-tokens-before USER TIMESTAMP). You can also use stateless tokens and store them in a database until they each expire, and then just list all outstanding tokens for the user in your revocation list. Nothing says you can't use a stateless token and store it. > Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier? You have to execute your consensus protocol once for each datum synced across the cluster. It's cheaper to run that protocol once each for a short list of items than it is to run it once each for a long list of items. 'Hey everybody, please invalidate the following item, confirm!' once in a blue moon is cheaper than 'hey everybody, someone logged in, confirm!' over and over again.
- mwpmaybe 10y agoWhat does the revocation list look like? "Reject all tokens for user X issued before timestamp Y?" Or do you assign UUIDs to your tokens?
- numbsafari 10y agoI assign a unique ID for each token (the `jti` claim). So each token has a unique identifier and can be invalidated that way, and every token has the user's ID (the `sub` claim), and can be invalidated that way, if that fits your use case.
- deleted 10y ago[deleted]
- mwpmaybe 10y agoI read this wrong the first time. That makes sense. Thank you.