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.

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.

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.

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.

"old hacked sessions to be used"

JWTs generally contain an expiration timestamp.

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.

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.

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.

it's my understanding something like Redis is good for cross cluster im-memory persistence/reference