Introspection endpoint per request versus short-lived JWT with cached revocation: selecting cache TTL for latency-sensitive APIs

Goal

Determine an appropriate cache lifetime for OAuth introspection responses that satisfies low-latency validation while providing acceptable revocation guarantees for latency-sensitive APIs.

Constraints and uncertainty

• OAuth 2.0 (RFC 6749) and JWT profiles (RFC 7519) express time-based claims in UTC; the spec does not prescribe how an authorization server’s introspection endpoint (RFC 7662) should be cached.
• Per-request introspection yields real-time active status but adds a network round-trip, increasing validation latency.
• Short-lived, self-contained JWTs validated locally eliminate that round-trip, yet revocation only takes effect after the token’s expiry unless a separate revocation cache is used.
• There is no normative guidance on how long introspection results may be cached or what staleness is tolerable for revocation.

What maximum acceptable staleness for revocation can be tolerated given the API’s latency budget? How should the cache TTL be tuned relative to observed token revocation frequency and issuance patterns? Should the resource server treat a cached introspection response as stale after a fixed period and fall back to a fresh introspection call?