Token Introspection

The core function of introspection is determining if a token is currently active. The authorization server returns a boolean active claim. If false, the resource server must treat the token as invalid. This provides a real-time revocation mechanism, instantly blocking access when a token is revoked or expired, without relying on cached token validation.

Beyond simple validity, the introspection response returns a JSON object containing the token's claims, such as:

• scope: The authorized scopes (e.g., inference:execute model:read)
• client_id: The client to which the token was issued
• username: The resource owner identifier
• exp: The expiration timestamp This allows the resource server to make fine-grained authorization decisions without parsing the token itself.

Introspection is essential for opaque tokens—tokens that are random strings with no embedded meaning, unlike structured JWTs. Since the resource server cannot decode an opaque token, it must present it to the authorization server's introspection endpoint to retrieve the associated metadata. This decouples token format from resource server logic.

The introspection endpoint itself must be protected. The resource server authenticates to the authorization server using HTTP Basic authentication with its client_id and client_secret, or a bearer token. This ensures that only authorized resource servers can query token metadata, preventing unauthorized information disclosure about active tokens.

To avoid overwhelming the authorization server, resource servers should cache introspection responses for a short duration. The exp claim in the response indicates the token's absolute expiry, allowing the cache TTL to be set safely. This balances real-time revocation needs with low-latency inference API performance, critical for high-throughput model serving.

Introspection works in tandem with the Token Revocation endpoint (RFC 7009). When a token is revoked—due to logout, compromise, or administrative action—the authorization server immediately marks it as inactive. The next introspection request for that token returns active: false, enforcing the revocation across all resource servers without delay.

The architectural component that intercepts every inference API request and calls the token introspection endpoint. The PEP extracts the bearer token from the Authorization header, queries the authorization server, and enforces the returned active state and scope claims. It is the gatekeeper in a zero-trust model serving mesh.

Every token introspection call generates a log event capturing the token's active state, associated scope, and the resource server that queried it. Storing these events in a WORM-compliant (Write Once, Read Many) system creates a non-repudiable record. This is essential for compliance frameworks like SOC 2 and the EU AI Act when serving models that process sensitive data.