Category: Tokens & Sessions

Token Revocation

Also known as: Token Invalidation

Simply put

Token revocation is the process of telling an authorization server that a previously issued token should no longer be accepted, so the associated access can be cut off. This is typically used when a token is no longer needed or when access must be terminated, for example after a user logs out or a security incident occurs.

Formal definition

Token revocation is a mechanism in the OAuth 2.0 ecosystem by which a client, or in some designs an external party such as a security incident management tool or identity provider, notifies the authorization server that a previously obtained access token or refresh token should be invalidated. In many deployments this is implemented through a dedicated revocation endpoint (for example, the OAuth token revocation endpoint exposed by products such as PingFederate and Amazon Cognito) where the client submits the token to be revoked; revoking a refresh token typically also invalidates access tokens derived from it, depending on configuration. Enforcement behavior varies: self-contained tokens such as signed JWTs may remain technically verifiable until expiry unless the resource server performs an introspection or revocation check, so the effectiveness of revocation depends on how relying parties validate tokens. Proposed extensions such as Global Token Revocation aim to let external parties trigger revocation across systems, but that work is an in-progress IETF draft rather than a finalized standard, and the exact scope and adoption are not settled here.

Why it matters

Tokens are the currency of delegated authorization in OAuth 2.0 ecosystems, and once issued they generally remain valid until they expire. Without a revocation mechanism, there is no reliable way to cut off access before that expiry, which becomes a problem when a user logs out, when a client no longer needs a token, or when a security incident requires access to be terminated quickly. Token revocation gives clients a way to notify the authorization server that a token should be invalidated, enabling clean termination of access rather than waiting for a token's natural lifetime to run out.

A critical nuance is that revocation is not automatically self-enforcing for all token types. Self-contained tokens such as signed JWTs may remain technically verifiable until they expire unless the resource server performs an introspection or revocation check, so revoking a token at the authorization server does not, on its own, guarantee that every relying party stops honoring it. The practical effectiveness of revocation therefore depends heavily on how relying parties validate tokens in a given deployment. Teams that assume a revocation call instantly severs all access may be surprised to find that short-lived JWTs continue to be accepted by services that do not check revocation state.

Revocation also intersects with incident response. In many designs the party triggering revocation is the client itself, but proposed work such as the IETF Global Token Revocation draft aims to let external parties, for example a security incident management tool or an external identity provider, trigger revocation across systems. That work is an in-progress draft rather than a finalized standard, so its scope and adoption should not be treated as settled. Nonetheless, it illustrates why revocation matters beyond routine logout: the ability to rapidly and broadly invalidate compromised access is a core operational need.

Who it's relevant to

IAM and Platform Engineers

Engineers building or integrating OAuth 2.0 clients need to know how to call the authorization server's revocation endpoint and understand that revoking a refresh token typically also affects access tokens derived from it, depending on configuration. They should verify the specific behavior of their authorization server product, such as PingFederate or Amazon Cognito, rather than assuming a uniform result.

Security Architects

Architects must account for the gap between revocation at the authorization server and actual enforcement at resource servers. For self-contained JWTs that are validated locally, revocation may not take effect until expiry unless introspection or revocation checks are added, so architects need to design token lifetimes and validation flows with this limitation in mind.

Incident Response and SecOps Teams

Teams responsible for cutting off compromised access care about how quickly and broadly tokens can be invalidated during an incident. Emerging work such as the IETF Global Token Revocation draft is aimed at letting external parties like security incident management tools trigger revocation across systems, but because it is an in-progress draft rather than a finalized standard, teams should not depend on it as settled capability today.

Application Developers Consuming Tokens

Developers of resource servers and relying parties determine whether revocation is honored in practice. Those validating tokens locally need to understand that a signed token remaining verifiable is not the same as it remaining authorized, and that supporting prompt revocation may require adding introspection or revocation checks to their validation logic.

Inside Token Revocation

Revocation Endpoint (RFC 7009)

An OAuth 2.0 endpoint where a client submits a token to request its invalidation. It typically accepts either access tokens or refresh tokens, and in many implementations revoking a refresh token also invalidates associated access tokens, depending on server configuration.

Refresh Token Revocation

Invalidation of a long-lived refresh token so it can no longer be exchanged for new access tokens. Because refresh tokens are typically the mechanism for obtaining fresh credentials, revoking them is often the most effective way to terminate ongoing access.

Access Token Revocation

Invalidation of an access token. For self-contained (for example JWT) access tokens, immediate revocation is difficult because resource servers may validate them locally without contacting the authorization server, so revocation often takes effect only when the token expires or when introspection is used.

Token Introspection (RFC 7662)

A mechanism by which a resource server queries the authorization server to check whether a token is currently active. Introspection enables near-real-time revocation checks for opaque tokens, at the cost of a network round trip per validation in most deployments.

Opaque vs. Self-Contained Tokens

Opaque tokens carry no embedded claims and must be validated against the issuer, making them straightforward to revoke by server-side state. Self-contained tokens such as signed JWTs are validated locally, which complicates immediate revocation and typically relies on short lifetimes or introspection instead.

Session and Credential Termination Triggers

Events that commonly prompt revocation, such as user logout, password change, detected compromise, administrative deprovisioning, or policy changes. These triggers connect runtime revocation to identity lifecycle and governance decisions, though the actual enforcement is a runtime concern.

Common questions

Answers to the questions practitioners most commonly ask about Token Revocation.

Does revoking a token immediately stop it from being accepted everywhere?

Not necessarily. For self-contained tokens such as signed JWTs, resource servers that validate the token locally by checking the signature and claims will typically continue to accept it until it expires, because they do not consult the authorization server on each request. Immediate, system-wide invalidation generally requires either short token lifetimes, introspection against the authorization server, or a shared revocation mechanism that PEPs actually check. The effect of revocation therefore depends on how tokens are validated in your deployment.

Is revoking a token the same as revoking the underlying session or the user's access rights?

No. Token revocation is a runtime enforcement action that invalidates a specific credential, most commonly a refresh token or an access token. It does not by itself change the user's session state at the identity provider, nor does it modify the authorization decisions or entitlements governed by IGA processes. Removing a user's roles or entitlements is a separate governance concern; depending on configuration, deprovisioning may trigger revocation, but the two are distinct steps that should not be conflated.

How can I make revocation effective for self-contained JWTs that are validated locally?

Because locally validated JWTs are not checked against the authorization server per request, deployments typically combine short access token lifetimes with revocable refresh tokens, so that a revoked refresh token prevents new access tokens from being issued. Where near-real-time invalidation of access tokens is required, options include switching to token introspection, maintaining a distributed denylist keyed on a token identifier such as the jti claim, or propagating revocation events to resource servers. Each approach trades off latency, statefulness, and operational complexity, and the right choice depends on your risk tolerance and infrastructure.

What is the difference between the RFC 7009 revocation endpoint and the introspection endpoint?

The OAuth 2.0 Token Revocation specification (RFC 7009) defines an endpoint where a client can request that a given token be invalidated, typically a refresh token or an access token. Token introspection (RFC 7662) is a separate endpoint that lets a resource server query the authorization server to determine whether a token is currently active and to retrieve associated metadata. Revocation changes token state; introspection reports token state. They are often used together, but they serve different purposes and should not be substituted for one another.

Should revoking a refresh token also revoke its associated access tokens?

Behavior here varies by vendor and configuration and is not uniformly guaranteed by the specifications. Some authorization servers cascade revocation so that revoking a refresh token also invalidates access tokens issued from it, while others revoke only the specific token presented. Even where cascading is configured, already-issued access tokens that are validated locally may remain usable until expiry. You should confirm your provider's documented behavior rather than assuming a particular outcome.

How do short token lifetimes interact with a revocation strategy?

Short access token lifetimes are frequently used to bound the window during which a compromised or no-longer-authorized token remains usable, which reduces reliance on immediate revocation for those tokens. In many deployments the durable credential is the refresh token, so the revocation strategy focuses on revoking refresh tokens while letting access tokens expire naturally. Shorter lifetimes increase token issuance traffic and refresh operations, so the interval is typically chosen to balance exposure risk against performance and availability considerations.

Common misconceptions

Revoking a token immediately blocks all access everywhere.

For self-contained tokens like signed JWTs, resource servers often validate the token locally without contacting the issuer, so a revoked token may continue to be accepted until it expires unless introspection or another server-side check is enforced. Immediacy depends on the token type and validation model.

Revoking an access token and revoking a refresh token are equivalent.

These are distinct tokens with different roles. Revoking a short-lived access token has limited effect if the client still holds a valid refresh token, while revoking the refresh token typically stops the client from minting new access tokens. In many implementations refresh token revocation also cascades to related access tokens, but this is configuration-dependent.

A signed token cannot be revoked because it is cryptographically valid.

A valid signature only proves integrity and authenticity, not that the token is still authorized for use. Revocation is a separate state check; whether it is enforced depends on using introspection, a revocation list, short token lifetimes, or opaque tokens rather than on the signature itself.

Best practices

Prefer short-lived access tokens paired with revocable refresh tokens so that even without immediate access token revocation, exposure is bounded by a short expiry window.

Use token introspection or opaque tokens for scenarios that require near-real-time revocation, and reserve locally validated self-contained tokens for cases where short lifetimes provide acceptable risk.

Implement the revocation endpoint per RFC 7009 and configure whether revoking a refresh token cascades to associated access tokens, documenting the chosen behavior explicitly.

Wire revocation triggers to identity lifecycle events such as logout, password change, compromise detection, and deprovisioning, so runtime enforcement reflects governance decisions.

Verify how each resource server validates tokens and confirm that revocation actually takes effect in that path, rather than assuming revocation propagates uniformly across all services.

Monitor and log revocation requests and introspection failures to detect misuse and to confirm that terminated credentials are no longer accepted.