Visual RFC.
ALL RFCs / RFC 6750
Read the RFC ↗
RFC 6750 / MECHANISMS

Put it in the request header

02

The Authorization header is the standard bearer-token request mechanism.

Related RFCs and changes

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

DIAGRAM§ 2.1 ↗
RFC 6750 · § 2.1EXAMPLE
3 / 3
Put it in the request headerThe Authorization header is the standard bearer-token request mechanism. Current state: Resource-server check.Put it in the request headerGET /resourceHost: api.exampleAuthorization: Bearer TOKENprotected requestresource checks
03
Resource-server check

Validate the token and required permissions over protected transport.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Clients should use the Authorization: Bearer method.

  • Clients should use the Authorization: Bearer method.
  • Resource servers must support it.
  • Do not use more than one token-transmission method in a request.
DETAILS

The illustration is schematic. Example values are illustrative; profiles and later security guidance can add requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Possession is the credential
  2. Put it in the request header
  3. URLs leave extra copies
  4. Errors describe different failures
  5. Limit the damage of disclosure

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 ↗