1. Question and Context
Multiple API resource servers accept access tokens issued by an authorization server. They need to know whether a token is active, which client owns it, which scopes it has, and when it expires. Security also needs fast revocation for stolen tokens. The design must balance real-time revocation, low latency, and authorization-service availability.
2. What the Interviewer Is Evaluating
- Whether you understand RFC 7662 introspection and RFC 7009 revocation semantics.
- Whether caches, revocation events, and versions prevent stale active results from hiding revocation.
- Whether you distinguish opaque tokens, local JWT validation, and proof-of-possession such as DPoP.
- Whether outage, retry, tenant-isolation, and audit policies are explicit.
3. Clarifying Questions Before You Answer
- Are the tokens short-lived access tokens, refresh tokens, or both?
- Do you revoke one token, a grant, a user session, or an entire client?
- How much revocation propagation delay can resource servers accept?
- Do you need to bind a client key or DPoP public key to prevent copied bearer-token replay?
4. A 30-Second Answer Framework
Use endpoint, source of truth, cache, revocation propagation, and failure policy.
The authorization server exposes protected introspection and revocation endpoints. The state store keeps a token hash, client, scopes, expiry, and revocation version. Resource servers cache active results for a short TTL and subscribe to revocation events to delete entries immediately. High-risk scopes fail closed during an authorization outage; low-risk requests may use an unexpired positive cache briefly. Queries, revocations, and failures are audited.
5. Step-by-Step Deep Dive
Step 1: Define Token State and Endpoint Authorization
Only trusted resource servers may call introspection. Return the necessary fields such as active, client_id, username, scope, exp, iat, and sub without exposing unnecessary identity data. The revocation endpoint authenticates its caller and token type, follows RFC 7009 for repeated revocations, and does not reveal whether an already-invalid token existed.
Step 2: Design State Storage and Indexes
Use a token fingerprint or hash as the key. Store issue time, expiry, grant ID, client, scopes, state version, and revocation reason. Index grant ID for bulk revocation; keep sensitive plaintext out of logs. Shard by tenant or hash so one client cannot become a hot partition.
Step 3: Handle Cache and Revocation Propagation
Cache positive results for a short TTL; avoid long negative caches. After revocation, publish the token fingerprint and state version. Resource servers delete local entries immediately; periodic pulls or version checks repair missed events. Force online introspection for high-risk actions when real-time revocation is worth the latency.
Step 4: Handle Failure, Retry, and Proof of Possession
Use exponential backoff and circuit breaking on introspection timeouts so resource servers do not overload the authorization service. During an outage, choose fail-closed or brief use of an unexpired positive cache by scope risk. With DPoP, also verify the request proof against the public key bound to the token, reducing replay risk for copied bearer tokens.
6. High-Quality Sample Answer
I would split the system into authorization endpoints, introspection, revocation, a state store, a revocation event bus, and a resource-server SDK. The state store is keyed by a token hash and keeps client, scopes, issue and expiry times, grant ID, revocation state, and version. Introspection returns only fields a resource server needs and requires caller authentication.
>
The SDK caches ordinary scopes for thirty seconds and introspects high-risk scopes online. Revocation supports one token and grant-wide revocation, then publishes a versioned event. The SDK deletes its cache on receipt, while a periodic repair job handles missed events. A positive cache entry whose version no longer matches must be re-introspected before use.
>
On authorization timeout, low-risk requests may use an unexpired positive cache while high-risk requests are rejected. Circuit breaking and jittered retries prevent a cascade. With DPoP, the SDK verifies the request proof and bound key. Queries, revocations, cache hits, and failures go to redacted audit storage so the spread of a stolen token can be traced.
7. Common Failure Modes
- Treating local JWT signature validation as real-time revocation.
- Caching active results for a long time without revocation events or version checks.
- Exposing introspection publicly or returning unnecessary user fields.
- Failing open for every request during an authorization outage.
- Retrying without timeouts, circuit breaking, or jitter and causing an authentication stampede.
8. Follow-Up Questions and Responses
Follow-up 1: Why should negative caches usually be shorter?
A token may have just been issued, a replica may be stale, or revocation may still be propagating. A short negative cache avoids turning temporary absence into a long invalidity window.
Follow-up 2: Should revoking a refresh token also revoke access tokens?
Use the grant and security policy. If a refresh token is stolen, normally revoke remaining tokens under that grant and let resource servers invalidate caches through versions or events.
Follow-up 3: How do you prevent duplicate or out-of-order revocation events?
Include a monotonic version or revocation time. Consumers accept only a version at least as new as local state; duplicate events remain idempotent, and an old event cannot restore an active state.