4 ms·
The state necessary to revoke JWTs is easier to manage than session state. 1. It's small (id per revoked, nonexpired JWT) 2. It isn't sensitive, nobody learns
by mgraczyk 7y ago
The state necessary to revoke JWTs is easier to manage than session state.
1. It's small (id per revoked, nonexpired JWT)
2. It isn't sensitive, nobody learns anything by seeing the list of revoked JWT ids.
3. It's monotonic. You just maintain a set that you add to. You can clean up expired tokens if you want but that's not necessary for correctness.
These three items make bugs less likely and make it easier to manage consistency when you can't afford to use transactions everywhere.
- namibj 7y agoThe monotonicity alone makes the required state _very_ easy. Adding (timestamp, jwt_id) pairs to a monotonic set which you occasionally switch over to a second, fresh set (checking against both, adding to one) requires zero coordination in the critical path. The only coordination required is about when the sets are switched, where you need to ensure that you leave ample time for old JWTs to expire before clearing the corresponding revocation set entries.
- mikeymz 7y agoRather than blacklist JTIs would it not be simpler to keep a valid after date on the user? Any token issued before that date is not acceptable
- mgraczyk 7y agoThen you can't have users sign out of device A while remaining signed into device B.