Visual RFC.
ALL RFCs / RFC 7009
Read the RFC ↗
RFC 7009 / OAUTH TOKEN REVOCATION

Propagate revocation to resource servers

05

An authorization server changing its state and every resource server learning that change are different events. Token architecture determines how revocation reaches the API.

DIAGRAMRead RFC section 3 ↗
RFC 7009 · § 3EXAMPLE
3 / 3
Propagate revocation to resource serversA reference-token resource server queries authorization state and receives revoked before denying access. The self-contained-token comparison instead separates authorization-server revocation time t0 from the resource server learning time t1, visibly marking the propagation window. A third design has no immediate signal: existing access persists at most to the illustrative access-token expiry while a revoked refresh token cannot renew it. Time positions are schematic, and no post200 reuse by the legitimate revoking client is shown.Revoked state must reach the APIIssue ATRevoke RTAT expiryExisting access-token lifetimeNo immediate revocation signalrenewal blockedShort-lived is a design choice, not a fixed duration
03
A short lifetime bounds exposure without immediate signaling.

An already issued access token may remain valid until its own expiry in this architecture. Revoking its refresh token prevents renewal, but does not itself rewrite signed token bytes.

Source for this drawing: RFC 7009 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 6749 OAuth 2.0 RFC 6750 Bearer tokens RFC 9110 HTTP

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Reference token
A token used as a handle to authorization data held elsewhere.
Self-contained token
A token carrying information that can be validated without a live lookup, subject to the deployment’s design.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

RFC 7009 describes both reference tokens checked against server-side authorization data and self-contained tokens a resource server can validate without another lookup.

  • RFC 7009 describes both reference tokens checked against server-side authorization data and self-contained tokens a resource server can validate without another lookup.
  • A reference-token design can learn current state when the resource server consults the authorization server. That lookup is an illustrative backend, not a new wire protocol defined here.
  • For self-contained tokens, immediate revocation can require backend communication. RFC 7009 does not standardize that backend mechanism.
  • Short-lived access tokens are an alternative design limiting continued use while refresh-token revocation prevents renewal. Implementations should minimize propagation delay; clients must not use tokens after the 200 response.
DETAILS

The timeline’s t0, t1 and expiry labels are ordering markers, not specified time limits. The delayed resource server is a separate observer; the legitimate revoking client does not keep using its token after success. Rejecting a revoked token does not automatically imply HTTP 403: resource protocols choose their own errors. Current OAuth security guidance, including RFC9700, complements this extension; it is not an obsoletion of RFC7009.

Read the RFC section ↗

All chapters in RFC 7009

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗