Yeah, we work on this issue all the time as well and see all of these solutions (and others). I agree that (A) definitely feels like sessions. However, I disagr

Yeah, we work on this issue all the time as well and see all of these solutions (and others). I agree that (A) definitely feels like sessions. However, I disagree that (C) is error prone. Here are answers to your questions on (C) plus how FusionAuth does it: > what if your webhook doesn't get processed quickly enough? I'm assuming you mean at the edges. This is possible, but if you are on the same backplane, highly unlikely since our solution is simply inserting an int into a Hash. Even if it isn't backplane, then you still can retry. Think of session caches as the same situation, so really no difference if you have a distributed cache for (A). Also, FusionAuth provides configurable timeouts and transactions for Webhooks. This covers most failure cases. > What if your client breaks and stops being able to accept webhooks? I'm assuming you mean "service" rather than "client" since we want the services to know a JWT has been revoked. I'd say this should hopefully mean that the service is also not accepting API requests. If it is, then you will have issues. However, this is a failure case no matter what. Similarly, the client breaks and stops validating the JWT in (A), you are in the same situation. Plus, FusionAuth provides transactional Webhooks, so you can retry and protect against failures. > What if the webhook server stops firing or gets overloaded? Since FusionAuth is the Webhook event generator and the IdP, if it stops, you got bigger issues. :) In terms of overloading, we protect against event backlogs and failures pretty well. We can also shut the entire node down if needed to prevent any API calls. This is a bit brute force, but if you are in #3 for security, turning everything off is better than a breach.