4 ms·
brilliant reply. you covered it top-to-bottom. usually people will gloss over or neglect something. You didn't cover the case (2.5) where you make a best effor
by jiveturkey 8y ago
brilliant reply. you covered it top-to-bottom. usually people will gloss over or neglect something.
You didn't cover the case (2.5) where you make a best effort to invalidate immediately, but don't need absolute guarantee of that as long as you know it will be eventually consistent, where 'eventually' is bounded. This relaxation of requirements can be liberating.
Didn't read TFA, but another way to distribute the blacklist to the edge is to return it along with other data. This isn't going to be a portable library or subsystem, if it works at all it depends very much on your arch and it will be custom.
> why use a JWT at all
because the JWT can carry other information, eg authz, in a portable way and that can be consumed by other backends. the portability of the JWT may also allow for much easier debugging. why not use a JWT? there's no disadvantage if you just process it like a normal signed session ID.
- rdegges 8y agoThe only disadvantage is that: 1. You are now passing large blobs of data over the network more frequently than just a signed session ID 2. If you want to ensure consistency of your data (for security purposes), that extra data embedded in the claims of the JWT are useless since you need to query for them for freshness after validating the session anyway.