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

Related tokens follow distinct cascade rules

04

Revoking one token may also affect related tokens and the authorization grant. Which relationship and which token type matter.

DIAGRAMRead RFC section 2.1 ↗
RFC 7009 · § 2.1EXAMPLE
3 / 3
Related tokens follow distinct cascade rulesGrant G1 links a refresh token RT1 and issued access tokens AT1 and AT2. With supported access-token revocation, the first state illustrates the SHOULD cascade from revoked RT1 to both access tokens. The next illustrates the optional MAY reverse cascade from requested AT1 to its refresh token, with no claim about additional access tokens. In the third, access-token revocation is unsupported: revoked RT1 prevents renewal while the existing AT1 remains active until its own lifetime or other controls end it. Unrelated grant G2 is outside each example.Same grant, different cascade rulesIllustrative grant G1RT1 REVOKEDAT1 still ACTIVEnew token issuanceAT1 lifetime → expiryNo immediate access-token invalidation hereG2: unrelated grant · outside this example
03
Recognize the limit when access-token revocation is unsupported.

The refresh token stops issuing new access tokens, but the existing access token can remain usable until its own lifetime or other controls end it. Local deletion is not an immediate global kill switch.

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

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
Authorization grant
The underlying authorization from which related tokens are issued.
Cascade
Invalidating related credentials because one token was revoked.
Related RFCs and changes

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

KEY POINT

The token actually being revoked is invalidated immediately. Related-token and grant invalidation depend on the authorization server’s policy.

  • The token actually being revoked is invalidated immediately. Related-token and grant invalidation depend on the authorization server’s policy.
  • If a refresh token is revoked and the server supports access-token revocation, it SHOULD also invalidate all access tokens based on the same authorization grant.
  • If an access token is revoked, the server MAY revoke its corresponding refresh token. That reverse cascade is optional, not a MUST.
  • When access-token revocation is unsupported, revoking the refresh token does not immediately invalidate existing access tokens. Clients must be prepared for unexpected invalidation at any time.
DETAILS

The diagrams use two illustrative grants G1 and G2, not actual authorization data. They show a selected cascade policy satisfying the recommendation in the first case, an optional reverse cascade in the second, and lack of immediate access-token invalidation in the third. Do not infer revocation of unrelated grant G2 or every login session. Grant-level invalidation is possible policy, not an unconditional all-tokens rule.

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 ↗