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

Answer first

For a latency‑sensitive API the cache TTL for introspection responses should be set to the largest value that keeps the post‑revocation exposure window within the tolerance you have agreed for your application. In other words, the staleness introduced by caching must not allow a revoked token to be accepted for longer than the time you are willing to tolerate that risk.

Confirmed facts

• RFC 7662 defines the introspection response but does not prescribe any caching policy.
• A short‑lived JWT (e.g., 5–15 minutes) can be validated locally, but revocation only propagates at token expiry unless a separate revocation check is performed.
• Caching an introspection result removes the round‑trip latency but introduces a window of staleness equal to the cache TTL.

Likely explanation and tuning approach

The practical choice of TTL is driven by three measurable inputs:

• Token lifetime – the maximum age a token can reach before it naturally expires.
• Observed revocation frequency – how often tokens are revoked relative to the number of active tokens.
• Acceptable exposure window – the maximum duration after a revocation during which you are willing to accept that the token may still be accepted.

A common heuristic is to cache for a fraction of the token lifetime (e.g., 30–50%) but not to exceed the exposure window. For example, with a 10‑minute token and a 60‑second exposure tolerance, a TTL of 60 seconds is acceptable; a TTL of 5 minutes would expose the system to a revocation window that exceeds the tolerance.

If revocations are frequent or the exposure window must be very short, you can keep the TTL very low (e.g., 10–30 seconds) or fall back to per‑request introspection for tokens that appear revoked in a fast revocation store (Redis set, Bloom filter, etc.). Conversely, if revocations are rare and latency is critical, a longer TTL may be acceptable.

When to fall back to fresh introspection

Treat a cached entry as stale when its age exceeds the chosen TTL. On a cache miss or when a fast revocation check indicates the token may have been revoked, trigger a fresh introspection call. This keeps the hot path local for the common case while ensuring that revocation is enforced promptly when needed.

Missing diagnostic detail

To set a safe TTL you need to know the maximum post‑revocation exposure window you can tolerate (in seconds). Without that figure the TTL cannot be bounded safely.

Assumptions and uncertainty

• Token lifetimes and revocation patterns are stable during the period you are tuning the TTL.
• The network RTT to the introspection endpoint is the dominant component of per‑request validation latency.
• Any fast revocation cache used on the hot path is highly available and has negligible lookup latency.

Because these factors vary by deployment, the TTL recommendation should be validated against real traffic and latency measurements before being committed to production.