Summary

  • RFC 7662 lets a protected resource ask an authorization server whether a token is currently active and receive metadata relevant to that resource.
  • active: true is a meaningful token-state conclusion, but it is not approval of the requested application action, an execution record or a durable result receipt.
  • Caching introspection answers exchanges load and latency for freshness, so operators must keep token state, authorization policy and business outcome in separate evidence planes.

A green light with a defined jurisdiction

The attraction of token introspection is easy to understand. A bearer token reaches an API that cannot, or does not wish to, validate every property locally. The API sends the token to an introspection endpoint. The authorization server evaluates it and returns a JSON object whose one mandatory member is active. A false answer ends the inquiry cleanly. A true answer can bring back scope, client, user, token type, expiry, audience, issuer and other facts needed to continue.

That answer is not ceremonial. RFC 7662 says an active token is generally one the authorization server issued, that has not been revoked and that lies within its validity interval. The authorization server is expected to perform the checks that apply to the token, including expiration, not-before time, revocation and signature. It must also consider whether the token can be used at the protected resource making the call. A service that reduces active to “the endpoint returned 200” throws away the protocol’s central conclusion.

The opposite mistake is to give the conclusion more jurisdiction than it has. Introspection reports what the authorization server can establish about the token for the caller. It does not possess the protected resource’s full application state. It cannot know, merely from token status, whether an invoice is already settled, a trading limit is exhausted, a record is under legal hold or a maintenance window has closed the requested operation.

The useful sentence is therefore precise: the token is presently usable as authorization evidence at this protected resource. The dangerous abbreviation is broader: the request is approved.

Richer’s boundary is an interface, not a verdict

Justin Richer is the person named on RFC 7662, the IETF Standards Track specification for OAuth 2.0 token introspection. The document formalizes a boundary between two kinds of authority. The authorization server knows the token lifecycle and the grant behind it. The protected resource knows the operation being attempted, the object it would affect and the local policy that governs it.

OAuth’s underlying role model makes the separation visible. A client presents an access token to a resource server. The resource server validates the token and, if the request is acceptable, serves the protected resource. Introspection is one standardized way for that server to obtain validation facts. It is not a transfer of the resource server’s policy responsibility to the authorization server.

Suppose an active token carries a scope that sounds appropriate for updating an account. The resource server may still reject the request because the account belongs to another tenant, the caller is outside an approved network, the proposed value violates a limit, a stronger authentication event is required or the object has changed since the client last read it. Conversely, the resource server may map a compact scope into several actions under a documented local policy. RFC 7662 neither supplies nor audits that mapping.

This is why “authorization” needs two levels of description. The authorization server can state facts about the delegated credential. The application must decide whether those facts satisfy the policy of a concrete request. Collapsing the two creates a green-light event with no accountable owner for the last gate.

The answer may depend on who asks

Introspection is not necessarily a universal dossier. RFC 7662 allows the authorization server to shape its response according to the protected resource making the query. It may return different information to different callers and may restrict the scopes it discloses to those relevant to that resource. The same token can therefore produce answers that are both valid and intentionally unequal.

That property matters operationally. An introspection log copied from one API is not automatically proof of what another API was entitled to learn or do. The audience and resource context have to travel with the evidence. RFC 8707 reinforces a related distinction: a resource indicator helps identify where an access token is intended to be used, while scope describes requested access. Destination and permission are complementary constraints; neither is a business-operation result.

Optional response members need the same restraint. exp and nbf bound time. aud and iss help identify audience and issuer. client_id, username and sub identify different participants or subjects according to the token and deployment. jti is a token identifier. None of them becomes an invoice number, job key or database commit ID because it is convenient to place it in an audit row.

An active answer has a clock inside it

The word “active” sounds present-tense, but a distributed system can only report what it knew at a particular point. RFC 7662 explicitly permits protected resources to cache introspection responses. The reason is practical: a cache can reduce authorization-server load and remove network latency from every protected request. The cost is equally explicit. Longer caching weakens the liveness of the answer.

Consider a token introspected at 10:00 and cached as active for five minutes. At 10:01 the holder revokes it through the mechanism standardized in RFC 7009, or an administrator invalidates the underlying grant. Until the cache expires, the protected resource may continue to act on the earlier answer. Both components can be behaving according to their configured rules. The disagreement is temporal, not necessarily a software fault.

The cache lifetime is therefore a policy decision with a security consequence. It should relate to token lifetime, revocation expectations, operation sensitivity, authorization-server availability and the cost of a stale admission. A public catalogue read and a privileged account recovery action should not inherit the same freshness budget merely because they share an introspection client.

Nor does revocation unwind what has already happened. RFC 7009 invalidates tokens and, depending on the server, related grants or tokens. It does not cancel a shipment, reverse a funds transfer or erase data already changed. Token lifecycle governs future credential acceptance. Application remediation governs effects.

Validation is not a receipt

The final boundary appears after authorization. A protected resource can accept a request and still fail before committing it. It can commit the change and lose the response. A queue can accept work that a consumer later rejects. Two retry attempts can carry the same still-active token and each pass policy while referring to one human intention—or two.

No introspection member resolves that ambiguity. jti can correlate activity involving one token, but a single token normally authorizes many requests. A scope can constrain classes of action without naming an individual operation. The introspection transaction itself can be logged, yet its successful completion proves only that token information was returned.

Consequential APIs need their own durable operation identity. They may use an idempotency key, a client-supplied command ID, a conditional version or another domain-specific mechanism. They also need a result that can be queried after a timeout. Authentication evidence, the resource server’s authorization decision, operation identity, commit outcome and response delivery should remain separate records even if an observability system later joins them.

The point is not to diminish token introspection. It is to use it without asking it to impersonate the rest of the system. Richer’s specification gives protected resources a disciplined way to ask a narrow, difficult question about a token’s current state. Good architecture preserves that answer’s strength by refusing to make it testify about decisions and events it never observed.

Sources