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

A token-type hint is only a hint

02

A lookup hint can help the authorization server search faster, but cannot redefine a token or justify skipping other supported token types.

DIAGRAMRead RFC section 2.1 ↗
RFC 7009 · § 2.1EXAMPLE
3 / 3
A token-type hint is only a hintThe authenticated client submits refresh token RT-demo with the inaccurate access_token hint. A miss in the access-token lookup does not end the search: the next state adds the required fallback search across supported types and finds it in the refresh store. The final state is a separate failed-ownership outcome: RT-demo belongs to client B, so client A cannot invalidate it. The failure connector stops before the revoked state.A hint cannot replace the token or its checksAuthenticated client A · token RT-demoChosen hint: access_tokenToken owner: BRequester: Aownership failsInvalidate?REFUSED · token is not invalidated hereInvalid hint is ignored; wrong owner is different
03
Refuse revocation for another client’s token.

In this separate failed-ownership outcome, RT-demo belongs to client B, while client A made the request. The request stops before invalidating the token. A recognized foreign token is not the harmless invalid-token success case.

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
Token-type hint
An optional optimization suggestion, not authoritative type metadata.
Ownership check
Verifying that the token was issued to the client making the request.
Related RFCs and changes

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

KEY POINT

The initial hint values are access_token and refresh_token. Profiles and extensions MAY define additional registered values.

  • The initial hint values are access_token and refresh_token. Profiles and extensions MAY define additional registered values.
  • If lookup using a given hint fails, the server MUST extend its search across all supported token types. A server MAY ignore the hint entirely.
  • An invalid hint is ignored and does not influence the revocation response. A bad hint is different from a token type whose revocation the server does not support.
  • Finding a token does not authorize revocation: the token must belong to the requesting client. Appropriate denial-of-service countermeasures MUST cover extra lookup work.
DETAILS

This example assumes the client has already passed applicable authentication. The submitted token RT-demo really is a refresh token, while the chosen access_token hint is inaccurate. After fallback, the server still checks token ownership. Search ordering and database structure shown here are illustrative, not a mandated implementation.

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 ↗