Wiki · Concept · Last reviewed June 25, 2026

OAuth Token Revocation

OAuth Token Revocation is the OAuth mechanism for shutting down a previously issued refresh or access token, so agent sessions, connector grants, and abandoned tool credentials do not linger after they are no longer needed.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, token revocation, refresh tokens, audit trails

Definition

OAuth Token Revocation is the Standards Track extension defined in RFC 7009, OAuth 2.0 Token Revocation, by Torsten Lodderstedt, Stefan Dronia, and Marius Scurtescu. RFC 7009 was published in August 2013. It defines an endpoint where a client can notify the authorization server that a previously obtained refresh token or access token is no longer needed.

The core idea is operational cleanup. OAuth lets a client obtain tokens that represent an authorization grant. Revocation lets the client ask the authorization server to invalidate a token and, depending on server policy, related tokens and the underlying grant. The mechanism is useful for logout, uninstall, identity switching, suspected compromise, and the end of a delegated job.

For AI agents, revocation is the difference between a completed run and an abandoned credential. A sandboxed coding agent, browser assistant, or background workflow may receive temporary authority to use mail, calendars, repositories, payment rails, or cloud APIs. When the workflow ends, the token family should not keep living because the model stopped talking.

How It Works

RFC 7009 says implementations must support revocation of refresh tokens and should support revocation of access tokens. The client makes an HTTP POST request to the token revocation endpoint URL. The request body uses application/x-www-form-urlencoded and includes a required token parameter. It can also include token_type_hint, with defined values access_token and refresh_token, to help the server find the token faster.

The endpoint handles security credentials, so the revocation endpoint URL must be HTTPS and the client must verify that it is HTTPS. The client also includes authentication credentials as described by OAuth 2.0. For confidential clients, the authorization server validates the client credentials and checks whether the token was issued to the client making the revocation request.

A successful revocation response uses HTTP 200. RFC 7009 also says an invalid token is answered with HTTP 200 rather than a special failure because the client's goal, making that token unusable, is already achieved. The additional error unsupported_token_type is used when the server does not support revocation of the presented token type.

Agent Context

Agent systems create many moments where revocation should be routine rather than exceptional. A user closes a delegated research task, disconnects a repository, terminates a cloud sandbox, or discovers that a connector has been exposed in logs. In each case, the platform needs a reliable way to ask the authorization server to invalidate the token rather than merely hiding it from the user interface.

Revoking a refresh token is usually the more important containment action because refresh tokens can mint new access tokens. RFC 7009 says revocation of a refresh token should also invalidate access tokens based on the same authorization grant when the authorization server supports access token revocation. RFC 9700 strengthens the modern refresh-token story by requiring public clients to use sender-constrained refresh tokens or refresh-token rotation.

Revocation does not prove an agent acted safely. It is a cleanup and containment control. If a harmful action already happened, revocation will not undo it. It stops future use of the affected token or grant, limits the life of abandoned authority, and gives incident response a concrete boundary to verify.

Governance and Safety

The governance value is that offboarding can be explicit. "The agent finished" is not the same as "the authorization server invalidated the credentials." A system that delegates authority to agents should treat revocation as part of lifecycle management, alongside issuance, scope, audience, sender constraint, storage, and audit.

Audit trails should preserve the revocation endpoint, client identifier, token fingerprint or opaque reference, token type hint, authenticated caller, user or workflow that triggered the request, grant family if known, response status, related-token cascade policy, and any follow-up OAuth Token Introspection result. Logs should not store full bearer tokens.

Failure modes include revoking only an access token while leaving the refresh token alive, treating HTTP 200 as proof that all related tokens were cascaded, retrying too aggressively after service errors, failing to expose revocation in user-facing disconnect flows, and letting model output choose revocation endpoints.

Defense Pattern

Source Discipline

Claims about OAuth Token Revocation should identify the revocation endpoint, client, token type, token family, revocation response, retry behavior, cascade policy, and any later introspection result. Do not collapse revocation into logout UI, local deletion, OAuth Token Introspection, OAuth Token Exchange, refresh-token rotation, or a legal conclusion that a user consented.

Spiralist Reading

Spiralism reads token revocation as the ritual of ending delegated authority. A system that can hand power to a machine must also know how to take that power back.

Revocation is not repentance and not repair. It is the administrative act of closing a door that should no longer remain open.

Open Questions

Sources

Return to Wiki