Token Revocation and Introspection

In modern identity architectures, the choice between JSON Web Tokens (JWTs) and opaque tokens dictates the entire lifecycle management strategy. JWTs are self-contained and stateless, meaning a Resource Server can validate them without contacting the Identity Provider. This is efficient but dangerous when immediate session termination is required; a revoked JWT remains valid until its exp (expiration) claim passes. Opaque tokens, conversely, are random strings with no intrinsic meaning, shifting the burden of validation to the Authorization Server (AS). This article details the mechanisms defined in RFC 7662 and RFC 7009 that enable secure, stateful management of opaque tokens.

The Necessity of Stateful Validation

Opaque tokens are essentially keys stored in a backend database or cache. They offer two critical advantages over JWTs: revocability and auditability. Because the token value itself contains no user data, the AS holds the source of truth. If a user logs out, changes their password, or exhibits suspicious behavior, the AS can immediately invalidate the token record. A JWT, once signed, cannot be "un-signed." To revoke it, you must maintain a global blocklist, which negates the stateless benefit and introduces significant scaling challenges as noted in industry best practices for distributed systems.

Therefore, when security requirements demand immediate session termination, opaque tokens are the correct primitive, providing the immediate invalidation capability that JWTs lack by default. However, this shifts the validation cost from cryptographic signature verification (CPU-bound) to a network round-trip to the AS (network-bound), contrasting sharply with the stateless authentication model preferred by many high-scale applications.

RFC 7662: Token Introspection

As defined in RFC 7662, introspection is the mechanism by which a Resource Server (RS) queries the Authorization Server (AS) to determine if an opaque token is valid and to retrieve its associated claims. This is defined in RFC 7662.

The process is synchronous and occurs at the point of access control. When a client presents an opaque token in the Authorization: Bearer <token> header, the RS does not decode it. Instead, it makes an HTTP POST request to the AS introspection endpoint.

The Introspection Request

The RS sends a application/x-www-form-urlencoded POST request. The body must contain the token parameter and may optionally include the token_type_hint parameter (usually access_token or refresh_token) to help the AS locate the record efficiently.

POST /introspect HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
 
token=dGhpcyBpcyBhbiBvcGFxdWUgdG9rZW4=
&token_type_hint=access_token

The RS must authenticate itself to the AS, typically using a client secret or mutual TLS (mTLS), to prevent unauthorized actors from probing valid tokens.

The Introspection Response

The AS responds with a JSON object. The most critical field is active, a boolean indicating whether the token is valid and has not been revoked or expired.

{
  "active": true,
  "scope": "read:profile write:messages",
  "client_id": "resource-server-1",
  "username": "jane.doe",
  "exp": 1678901234,
  "iat": 1678814834
}

If active is false, the RS must reject the request with 401 Unauthorized. If true, the RS extracts the claims (like scope or username) from the response to make local authorization decisions. Note that the RS trusts the AS implicitly; the integrity of the introspection response is guaranteed by the transport layer (TLS) and client authentication.

RFC 7009: Token Revocation

Per RFC 7009, revocation is the act of invalidating a token before its natural expiration. This endpoint allows clients or Resource Servers to notify the AS that a specific token should no longer be used.

The Revocation Request

The revocation endpoint accepts a POST request with the token value and, optionally, its type. Unlike introspection, revocation is often initiated by the client during logout or by the RS if it detects anomalous behavior.

POST /revoke HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
 
token=dGhpcyBpcyBhbiBvcGFxdWUgdG9rZW4=
&token_type_hint=access_token

The client authenticates with the AS using the same credentials as the introspection endpoint. The AS removes the token from its active store.

Immediate vs. Deferred Invalidation

A common misconception is that revocation is instantaneous across all systems. In reality, revocation is a state change on the AS. If the RS has cached the validity of the token, it may continue to accept it until the cache expires. However, since opaque tokens are not self-contained, the RS must call the introspection endpoint for every request (or rely on a very short-lived cache). Therefore, once a token is revoked, the next introspection call will return "active": false.

This is distinct from JWT blocklists, where the blocklist itself must be synchronized across all instances of the Resource Server. With opaque tokens, the synchronization is handled internally by the AS's storage backend.

Operational Tradeoffs and Security

Implementing introspection and revocation introduces specific operational constraints, as detailed in the RFCs and industry best practices for OAuth 2.0 deployments.

Latency: Every protected API call now requires a network hop to the AS. This adds 10–50ms of latency depending on network topology. For high-throughput systems, this can become a bottleneck, representing a significant tradeoff against the performance benefits of stateless authentication. Mitigation strategies include caching introspection responses with a short TTL (e.g., 60 seconds) and ensuring the AS is geographically close to the RS.

Security Surface: The introspection and revocation endpoints are sensitive. They must be secured with mTLS or strong client authentication. Exposing these endpoints to the public internet without proper authentication allows attackers to enumerate valid tokens or revoke legitimate sessions. Furthermore, the token_type_hint parameter should be validated strictly to prevent injection attacks or confusion between access and refresh tokens.

Auditability: One of the primary benefits of opaque tokens is the audit trail. The AS can log every introspection and revocation event. This provides a clear chain of custody: who accessed the resource, when, and whether the session was later terminated. JWTs, being stateless, leave no such record unless the RS implements custom logging, which is often incomplete.

Conclusion

RFC 7662 and RFC 7009 provide the standardized mechanisms for managing the lifecycle of opaque tokens. Introspection allows Resource Servers to validate tokens securely, while revocation enables immediate session termination. While these mechanisms introduce latency and complexity compared to JWTs, they are essential for architectures requiring strict security controls, auditability, and the ability to invalidate sessions instantly. For backend developers, the tradeoff is clear: accept the network overhead to gain the security guarantee of stateful token management.