3 ms·

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state

by mcherm 10y ago

Yes you can. The system I built uses a revocation list (propagated to all servers in the cluster) to invalidate the session. Just as if you were storing state on the server, it still requires a means of propagating the user's state to every server. But we only need to propagate a single ID once per session (at logout) instead of propagating all the session data to all the servers on every request.

brndn 10y ago
Out of curiosity, how are you propagating the IDs to other systems in the cluster? I am building something which could benefit from pushing config data across a cluster.
- sk5t 10y ago
  In most cases it shouldn't matter; revocation lists ought to be trimmed to the lifetime of the issued tokens--when they are used at all, revoking a JWT rather than just letting it expire is likely not extremely common--so you could stuff them anywhere at all that is convenient to your other technology selections.
- centrinoblue 10y ago
  it's my understanding something like Redis is good for cross cluster im-memory persistence/reference
sb8244 10y ago
Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used? Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.
- RhodesianHunter 10y ago
  "old hacked sessions to be used" JWTs generally contain an expiration timestamp.
- hueving 10y ago
  revocation list only needs to contain tokens that haven't expired. If there is an 'event' that causes this info to be lost, then expire everything by changing the global secret.
- merb 10y ago
  The same problem occurs on every other method. i.e. Bearer/Cookies. As already said the most vulnerabilities applies to all methods. But people are just too blind to see that.
- mcherm 10y ago
  Not particularly. There are other layers of security here - the sessions expire (so there's a limited window to exploit each one), the sessions are always transmitted via SSL (so you pretty much have to have an exploit on the customer's system to get one), and the sessions are restricted to one customer (so you only have an attack against the customer whose system you have an exploit on). If we used a different approach, then the same error (losing the data that's being synched) would result in losing all of the customer sessions.
ademarre 10y ago
To revoke with a revocation list, you need to know the ID of the token being revoked. That only works if (a) the token is present at the event that triggered the revocation, or (b) you are tracking all tokens, in which case there's probably not much point to using JWTs at all. Another approach is what I call the "subject epoch" pattern. The subject of a token (the "sub" JWT claim) is often something like a user ID. When an event occurs that requires all tokens for a given subject to be revoked, save that time stamp as the subject's "epoch". When processing JWTs, those issued before the subject's epoch must be considered invalid.

by mcherm 10y ago

brndn 10y ago

Out of curiosity, how are you propagating the IDs to other systems in the cluster? I am building something which could benefit from pushing config data across a cluster.

sk5t 10y ago
In most cases it shouldn't matter; revocation lists ought to be trimmed to the lifetime of the issued tokens--when they are used at all, revoking a JWT rather than just letting it expire is likely not extremely common--so you could stuff them anywhere at all that is convenient to your other technology selections.
centrinoblue 10y ago
it's my understanding something like Redis is good for cross cluster im-memory persistence/reference

sb8244 10y ago

Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used? Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.

RhodesianHunter 10y ago
"old hacked sessions to be used" JWTs generally contain an expiration timestamp.
hueving 10y ago
revocation list only needs to contain tokens that haven't expired. If there is an 'event' that causes this info to be lost, then expire everything by changing the global secret.
merb 10y ago
The same problem occurs on every other method. i.e. Bearer/Cookies. As already said the most vulnerabilities applies to all methods. But people are just too blind to see that.
mcherm 10y ago
Not particularly. There are other layers of security here - the sessions expire (so there's a limited window to exploit each one), the sessions are always transmitted via SSL (so you pretty much have to have an exploit on the customer's system to get one), and the sessions are restricted to one customer (so you only have an attack against the customer whose system you have an exploit on). If we used a different approach, then the same error (losing the data that's being synched) would result in losing all of the customer sessions.

ademarre 10y ago

To revoke with a revocation list, you need to know the ID of the token being revoked. That only works if (a) the token is present at the event that triggered the revocation, or (b) you are tracking all tokens, in which case there's probably not much point to using JWTs at all. Another approach is what I call the "subject epoch" pattern. The subject of a token (the "sub" JWT claim) is often something like a user ID. When an event occurs that requires all tokens for a given subject to be revoked, save that time stamp as the subject's "epoch". When processing JWTs, those issued before the subject's epoch must be considered invalid.