4 ms·
If I understand the point being made here then the idea is that a stateless session via a cryptographically verified bearer token needs a stateful revocation li
by BlackFly 4mo ago
If I understand the point being made here then the idea is that a stateless session via a cryptographically verified bearer token needs a stateful revocation list to eliminate hijacking (a user logout should completely invalidate the login but a bearer token would otherwise continue to be valid) and if you are maintaining state then you can just use a complete stateful session and avoid the complexity of the cryptography.
This point is not made very clearly and is buried by overemphasising JWTs instead of just quickly pointing them out as an example of a stateless session. But yeah, it is a good point.
- bastawhiz 4mo agoRevocation lists can simply be replaced with a "tokens not valid before" field per user. When a user logs out, set the field to now(). Reject JWTs that have an iat less than that value. Am I missing something?
- Sohcahtoa82 4mo agoWhat you're missing is that you're still creating state. You're still having to check a database to determine what the "tokens not valid before" value is for that user. And what if the user is logged in from multiple devices, but only wants to log out from ONE of them? Your solution logs them out from all of them. The entire point is that it is not possible to have authentication that is both: 1. stateless. 2. secure. And so if authN is going to be stateful anyways, you might as well just use an opaque token in a database and eliminate all the complexities and foot-guns of JWTs.
- nijave 4mo agoThere is middle ground. Authn can be stateless and authz stateful. Usually it's impractical to shove all the authz nuance into a JWT anyway Doesn't address logging out a single session, though
- dchest 4mo agoYeah, you made a revocation list but with time value instead of the token value.