Opaque Tokens, Introspection and Revocation

active is the only field every caller must check first: false (or the whole set of extra fields simply absent) means the token is not currently valid, for any reason — expired, revoked, never issued, or malformed — and RFC 7662 §2.2 deliberately does not distinguish which, so the introspection response itself cannot be used to enumerate valid token identifiers. Every other field mirrors what a self-contained JWT would have carried in its claims, letting a resource server that supports both formats treat the two uniformly once validated.

Calling introspection on every single request adds a network round trip (and a hard dependency on the authorization server’s availability) to every API call. Resource servers typically cache a positive introspection result for a short, deliberately bounded TTL (seconds, not minutes) — short enough that a revocation still takes effect promptly, long enough to absorb request bursts from the same token without hammering the introspection endpoint. A negative result (active: false) is safe to cache more aggressively, since a token that is not valid now will not become valid later.

Plain JSON introspection responses are not signed — if the transport between resource server and authorization server is not fully trusted (an intermediary proxy, a multi-tenant AS shared across security domains), the response’s own integrity and audience cannot be verified the way a JWT’s can. RFC 9701 lets the authorization server return the introspection result as a signed (optionally encrypted) JWT instead of plain JSON — Accept: application/token-introspection+jwt on the request, application/token-introspection+jwt on the response — giving the same tamper-evidence and audience-restriction guarantees introspection otherwise lacks.

Revoking a refresh token is specified to invalidate the whole grant it came from: the refresh token itself, and, at the authorization server’s discretion, every access token already issued from it (RFC 7009 §2.1). This is the same mechanism Access and Refresh Tokens describes for reuse-detected refresh-token families — revocation is that same "kill the family" operation, just triggered deliberately (e.g. "log out everywhere", "user reported this device stolen") rather than by detected replay.

Revoking an opaque access token is immediate and complete: the very next introspection call returns active: false, because introspection is the live check.

Revoking a JWT access token run through this same endpoint only marks it revoked in the authorization server’s own records — it does not retroactively change what a resource server that validates the JWT locally will do, because that resource server never asks the authorization server anything. A revoked JWT keeps validating successfully, everywhere it is checked purely locally, until exp. This is the exact limitation already flagged on JWT and the JOSE Family: revocation only reaches a locally-validated JWT if something else bridges the gap — introspection used alongside the JWT (defeating much of the point of using a JWT), a short exp, or a deny-list the resource server also consults.

draft-ietf-oauth-status-list defines a compact, bitmap-based Token Status List an authorization server can publish and a verifier can fetch and cache cheaply, to check the revocation status of many by-value tokens (JWTs or similar) without a per-token network round trip. Each token carries a status_list claim pointing at an index into a published list; the verifier looks up that one bit locally against its cached copy of the list. It is a middle ground between "no revocation check at all" and "introspect every request" — still in progress as an Internet-Draft, but the direction the ecosystem is heading in for bridging revocation into by-value tokens without paying introspection’s full latency cost on every call.

A session (the resource owner’s authenticated relationship with the authorization server, often backed by a browser cookie) and a token’s lifetime are related but distinct clocks. Ending a session (logout) does not automatically revoke every access and refresh token already issued during it, unless the authorization server is explicitly built to cascade that — see Logout and Session Management for RP-initiated and back-channel logout, which is exactly the mechanism that closes this gap for OpenID Connect deployments.