An identity provider issues tokens that applications validate locally without a network call. What does that buy, and what is the necessary consequence for revocation?

What local validation buys

It removes the identity provider from the request path. An application validates a signature against a cached public key, which means the provider's availability is not a hard dependency of every authenticated request. For a provider on the critical path of thousands of applications, this is the single most important architectural decision — it caps the blast radius of their own outages.

It also removes latency and cost: no round trip, no per-request charge, no rate limit on the hottest operation in the system.

The necessary consequence

A revoked session remains valid until its token expires. There is no way around this within the model: the whole point is that nobody asks the provider, so the provider cannot say no.

The token lifetime is therefore the revocation SLA, and that must be stated rather than discovered. Fifteen minutes means a compromised session survives fifteen minutes; twenty-four hours means a day.

Resolving the tension

• Short-lived access tokens with refresh. The refresh call is checked against the provider, so revocation takes effect within one token lifetime. This is the standard resolution and it works.
• A revocation list for the exceptional case, fetched frequently, small, and fail-closed on refresh failure. Keeping it small is what makes frequent fetching affordable and a fail-closed posture safe.
• Critical operations re-check. A password change, a payout, an admin action can afford a synchronous verification even if ordinary requests cannot.
• Session versioning: a counter in the user record that tokens carry, so incrementing it invalidates every outstanding token for that user. This requires a lookup, so it is used for the operations that justify one.

The operation that most often causes a mass outage

Key rotation. Every application must fetch and trust the new public key before the old one stops signing. That requires an overlap window, a published key set that clients refresh automatically, and clients that handle an unknown key ID by refetching rather than by failing.

Rotation must be routine and rehearsed rather than exceptional, because a rotation that is performed rarely is performed badly — and its failure mode is every customer's application rejecting every login simultaneously.