Token Revocation

An access token is a short-lived credential used in OAuth 2.0 to authorize API requests on behalf of a user or client application. It contains encoded claims about the authorization grant, such as the client identity, user identity (if present), approved scopes, and an expiration time. The primary target for revocation, its limited lifespan (often minutes or hours) is a key security feature that bounds the impact of token leakage.

• Bearer Token: The most common type, where possession of the token string alone grants access.
• Structure: Often a JSON Web Token (JWT), allowing the resource server to validate its signature and contents without an immediate call to the authorization server.

A refresh token is a long-lived credential issued alongside an access token, used to obtain new access tokens without requiring the user to re-authenticate. It is a core component of the OAuth 2.0 authorization code and resource owner password flows. Because of its longevity and power, its secure storage and management are paramount.

• Revocation Target: Refresh tokens are a high-priority target for revocation, as invalidating one prevents the generation of any future access tokens for that session.
• Client Security: They must be stored confidentially by the client application, ideally in a secure enclave or using a hardware security module (HSM) for high-assurance scenarios.

Token introspection is an OAuth 2.0 extension (RFC 7662) that allows a resource server to query the authorization server about the active state and meta-information of an access token. This is a primary mechanism for implementing real-time revocation checks beyond simple JWT validation.

• How it Works: The resource server sends the token to a dedicated introspection endpoint. The authorization server responds with a JSON object indicating if the token is "active": true and includes claims like scope, client_id, and exp.
• Trade-off: Provides definitive, up-to-date token status but introduces latency and load on the authorization server compared to stateless JWT validation.

The authorization server is the central OAuth 2.0 component responsible for authenticating users/clients, obtaining consent, and issuing tokens. It is the sole entity with the authority to revoke tokens, typically exposing a dedicated token revocation endpoint (RFC 7009).

• Core Functions:
  • Hosts the /authorize, /token, /revoke, and /introspect endpoints.
  • Maintains the state of issued tokens and their validity.
  • Enforces client authentication (e.g., via client secret, mTLS, or private key JWT) before processing a revocation request.
• Architecture: Often implemented as part of identity providers like Okta, Auth0, or Keycloak.

A JSON Web Token is a compact, URL-safe token format (RFC 7519) commonly used as an OAuth 2.0 access token. Its structure enables stateless validation but also defines the challenge for immediate revocation.

• Structure: Header.Payload.Signature. The payload contains claims like exp (expiration), iat (issued at), and scope.
• Stateless Validation: A resource server can validate the JWT's signature and exp claim without contacting the authorization server, making it efficient.
• Revocation Challenge: This stateless nature means a revoked JWT will still pass signature validation until its natural exp time. Mitigations include using short expiration times, token introspection, or maintaining a small denylist of revoked token IDs (jti claims).

The OAuth 2.0 Threat Model and Security Considerations (RFC 6819) is the definitive security analysis of the OAuth 2.0 protocol. It catalogs threats and prescribes countermeasures, establishing the foundational rationale for token revocation.

• Key Threats Addressed by Revocation:
  • Token Leakage: If an access or refresh token is disclosed to an unauthorized party, revocation is the primary method to immediately terminate its usefulness.
  • Session Hijacking: Invalidation of all tokens for a compromised user session.
  • Client Compromise: Revoking all tokens issued to a malicious or lost client application.
• Security Best Practice: The RFC explicitly recommends providing a revocation endpoint as a critical security control.