Revocation Window

Signed tokens validated locally against a cached public key remove the identity provider from every authenticated request. For a provider on the critical path of thousands of applications, that is the single most consequential architectural decision available: it caps the blast radius of the provider's own outages and removes latency, cost and a rate limit from the hottest operation in the system.

The unavoidable consequence is that nobody asks the provider, so the provider cannot say no. A revoked session stays valid until its token expires.

Why it matters

The token lifetime is the revocation SLA, and it is frequently chosen for convenience by someone who has not connected it to the security question. Fifteen minutes means a compromised session survives fifteen minutes; twenty-four hours means a day of an attacker acting as the user after you believed you had removed them.

Stating it explicitly is what turns an implicit accident into a decision.

Implementation patterns

• Short-lived access tokens with refresh. The refresh call is checked against the provider, so revocation takes effect within one token lifetime. The standard resolution, and it works.
• A small revocation list, fetched frequently, fail-closed on refresh failure. Keeping it small is what makes frequent fetching affordable and a fail-closed posture safe.
• Synchronous re-check for critical operations — a password change, a payout, an administrative action can afford a round trip even when ordinary requests cannot.
• Session versioning: a counter in the user record that tokens carry, so incrementing it invalidates every outstanding token for that user at once. Requires a lookup, so it is reserved for operations that justify one.
• Automatic key-set refresh in clients, with an unknown key ID triggering a refetch rather than a failure — which is what makes rotation survivable.

Industry example

Identity providers such as Clerk, Auth0 and Okta all make this trade, and the operation that most often causes a mass outage across their customers is key rotation. Every application must fetch and trust the new public key before the old one stops signing, which requires an overlap window and clients that refresh automatically.

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

Failure scenarios

• Long token lifetimes chosen for convenience, making the revocation window hours.
• No refresh mechanism, so revocation is impossible until natural expiry.
• A large fail-closed revocation list, so a fetch failure denies broadly and causes an outage.
• Key rotation without an overlap window, or with clients that fail rather than refetch on an unknown key.
• Critical operations validated identically to ordinary ones, so the highest-consequence actions get the weakest freshness.

Trade-offs

Short token lifetimes mean more refresh traffic, which partially reintroduces the dependency that local validation removed — though at a small fraction of the request rate. Long lifetimes reduce that traffic and widen the window.

The resolution is asymmetric treatment: short lifetimes for the general case, synchronous verification for the small set of operations where a stale authorisation is unacceptable. Choosing one lifetime for everything optimises for whichever concern was raised loudest.

Interview question

"A customer reports a compromised account and asks you to log the attacker out. Tell me exactly when that takes effect in your system, why, and what you would change if the answer were unacceptable to them."