Limit token privileges
05A token should carry only the audience, resources, and actions the app actually needs.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 2.3 ↗
RFC 9700 · § 2.3EXAMPLE
4 / 4
04
A different door stays closed.
The payments server rejects this calendar token.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 3.3RFC 9700 § 2.3
Privilege restriction now explicitly includes audience, resources, and actions, with server-side checks on each request.
Read the updated RFC section ↗Restrict the audience and the action.
- Access-token privileges SHOULD be the minimum needed for the use case.
- Tokens SHOULD be limited to a specific resource server, or a small set. Servers MUST reject a token intended for a different audience.
- Restrict resources and actions as well. scope, resource, and authorization_details can express the intended bounds.
Audience restriction answers “where?” Scope and detailed authorization answer “what?” A token for reading a calendar should not become a general-purpose account key.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
PrivacyAll chapters in this RFC
- OAuth overview
- Authorization code + PKCE
- Retire unsafe grants
- Prevent token replay
- Limit token privileges
- Authenticate the client
- Metadata, TLS & CORS
- The attacker model
- Redirect URI validation
- Referer header leakage
- Browser history leakage
- Authorization server mix-up
- Authorization code injection
- Access token injection
- Cross-site request forgery
- PKCE downgrade
- Leakage at resource servers
- Misuse of stolen tokens
- Open redirection
- 307 credential forwarding
- TLS termination & proxies
- Refresh token protection
- Client as resource owner
- Clickjacking
- In-browser messaging