Scope and protected resources
10The client asks for privileges; the server decides what it actually grants.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 3.3 ↗
RFC 6749 · § 3.3EXAMPLE
3 / 3
03
Enforce the granted permission.
The resource server checks whether this token authorizes this operation.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 3.3RFC 9700 § 2.3
The BCP recommends minimal privileges, resource/action limits, and audience restrictions, with rejection of tokens meant for another resource server.
Read the updated RFC section ↗A requested scope is not automatically granted.
- Scopes are case-sensitive strings defined by the authorization server.
- The server may partially or fully ignore the requested scope based on policy and authorization.
- § 7 requires the resource server to validate the token and check the scope before serving protected resources.
Token validity and permission for a particular action are separate checks.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
PrivacyAll chapters in this RFC
- Four roles, one delegation
- Public and confidential clients
- Two endpoints, two channels
- Authorization code grant
- Implicit grant: historical behavior
- Password grant: now prohibited
- Client credentials and extension grants
- Token responses and failures
- Refresh without another prompt
- Scope and protected resources
- Native apps and security boundaries