4 ms·
All you really need for revocation in a revocation service are two fields: user id + inb (issued not before) and a bloom filter. To revoke a token: 1. issue a
by withinboredom 2y ago
All you really need for revocation in a revocation service are two fields: user id + inb (issued not before) and a bloom filter.
To revoke a token:
1. issue a new token to the revoker that is issued at current time (if business rules require revoker to be logged in).
2. set user inb to current time - 1 second with a TTL of longest issue * 1.5.
3. Add user to bloom filter.
4. upload bloom filter to s3, every service downloads this every 5 minutes.
5. Then on request, check bloom filter. If the user id is in the bloom filter, check with revocation service that inb > issued time.
This is probably less than five hundred lines of code and pretty easy to maintain.
- littlecranky67 2y agoOften overlooked middle-ground that vastly simplifies your revocation logic: Just have a single field "not-issued-before" timestamp assigned to each user account. Instead of revoking a single token, you have a "log out from all devices" logic - i.e. you revoke all tokens at once based on their "iat" claim (issued at). No need for revocation lists alltogether, you just make sure any tokens "iat" is never before the "not-issued-before" associated with the user. Sure, this is not as perfect UX as being able to revoke individual tokens, but token revocation in generall is something only a fraction of your uses is ever going to need.
- withinboredom 2y agoYeah, this works very well. A nice "log me out of everywhere, including this device" link is often all you need on the settings page. It also makes e2e testing very easy since you should be logged out after pushing that button.