A resource server that sends every access token to an introspection endpoint pays a network round trip for each request. Caching looks like an obvious optimization. The cache also becomes a local statement that a token is still active, and that statement can outlive a revocation decision at the authorization server.
OAuth 2.0 Token Introspection returns an active value and may return metadata such as scope, client identifier, subject and expiry. The resource server must treat a missing or malformed response as an error, not as an inactive token. A timeout is not proof that access should be denied, but it is also not evidence that access should continue.
Put a ceiling on every entry
Cache a successful active result only until the earlier of the token's exp value and a small configured TTL. A revoked token remains revoked at the authorization server, but the cache can continue to authorize it until the entry expires. The TTL is therefore a revocation-delay budget, not a generic performance setting.
Do not use a single long TTL for every client. High-value administrative scopes can use a shorter budget than read-only application scopes. If the authorization server provides signed introspection responses, verify the issuer, audience, signature and timestamp before caching the claims. A JWT wrapper does not remove the need for freshness.
Distributed resource servers need a coherent cache policy. Two pods with different TTLs can disagree about the same token for a visible interval. Use a shared invalidation path for emergency revocation or accept the documented delay and expose it in the service level objective.
Test the failure modes
Measure the time from revocation to rejection at each resource server. Repeat with the introspection endpoint unavailable, with a malformed response and with a token whose expiry is shorter than the cache TTL. Confirm that the resource server fails in the direction the application expects.
Record token identifiers in logs only in a protected, non-reversible form. Do not persist full introspection responses, which can contain user and client metadata. Keep enough fields to explain the decision without creating a second credential store.
The cache is useful when its lifetime is explicit. The policy should state how much revocation delay is acceptable, who can shorten it during an incident and how every resource server enforces the same ceiling.