Visual RFC.
ALL RFCs / RFC 7662
Read the RFC ↗
RFC 7662 / OAUTH TOKEN INTROSPECTION

The API asks about a presented token

01

A resource server receiving a token can ask the authorization server for its current state and metadata. The caller of introspection is the protected resource, not the original OAuth client.

RFC 7662 · § 2.1EXAMPLE
3 / 3
The API asks about a presented tokenThe OAuth client first sends an inspected token to the protected resource. The resource server then sends that subject token as a form body to the authorization server introspection endpoint. The final state separates the Bearer credential authorizing this lookup from the api-token-demo being inspected. The API does not obtain introspection authority merely from receiving a token from its client; endpoint discovery and authentication configuration are external to this example.The API asks the issuer about a tokenAuthorization: Bearer lookup-credential-demoCredential for this introspection callTwo different fields of one requesttoken=api-token-demoSubject token in the request bodyResource serverAuthorization serverboth fields in HTTPS POSTLookup credential ≠ inspected token
03
Authorize the lookup with a separate credential.

A separate Bearer lookup-credential-demo authorizes the resource server’s call. This does not turn the inspected api-token-demo into authority to scan other tokens.

Source for this drawing: RFC 7662 · Read RFC section 2.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Introspection
A network query about a token’s current state and related information.
Protected resource
The API or resource server deciding whether a token allows access.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Send an HTTP POST with application/x-www-form-urlencoded body data. token is REQUIRED; token_type_hint is OPTIONAL. Discovery of the introspection endpoint is outside this RFC’s scope.

  • Send an HTTP POST with application/x-www-form-urlencoded body data. token is REQUIRED; token_type_hint is OPTIONAL. Discovery of the introspection endpoint is outside this RFC’s scope.
  • Access to the endpoint MUST be authorized to prevent token scanning. Client authentication or a separate OAuth access token can authorize the resource server’s query; that credential is distinct from the token being inspected.
  • A supplied hint MAY be ignored. If lookup using it fails, the server MUST extend its search across all supported token types. The hint values come from the registry established by RFC7009.
  • Additional context parameters MAY be accepted, but their definitions are outside this RFC. If required context is missing and state cannot be determined, the server SHOULD report inactive.
DETAILS

Fictional token api-token-demo is the subject of the query. lookup-credential-demo is a different credential authorizing the introspection request. A resource server is not granted inspection rights merely by possessing a token received from a client. RFC7662 supports access and refresh tokens; other token types are outside this base specification. Endpoint names and credentials shown are illustrative, never production values.

Read the RFC section ↗

All chapters in RFC 7662

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗