Client credentials and extension grants
07A client can obtain access on its own behalf, without an interactive resource-owner redirect.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.4 ↗
RFC 6749 · § 4.4EXAMPLE
3 / 3
03
Use the client’s own authorization.
The API distinguishes the application principal from a user principal.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 4.4RFC 9700 § 4.15
The BCP addresses subject confusion: client-only and user-involved tokens must not become indistinguishable through colliding identifiers.
Read the updated RFC section ↗Machine authority is different from user delegation.
- The client credentials grant MUST be used only by confidential clients.
- The client authenticates at the token endpoint; a refresh token SHOULD NOT be included in this response.
- § 4.5 defines an extension point for additional authorization grants.
A token representing an application should not accidentally be treated as a human user’s authority.
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