Authorization code grant
04A short-lived code travels through the browser; tokens come from the token endpoint.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.1 ↗
RFC 6749 · § 4.1EXAMPLE
4 / 4
04
Use the resulting token at the API.
The resource server checks its authority.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 4.1RFC 9700 § 2.1.1
Public clients MUST use PKCE; confidential clients are RECOMMENDED to use it. Authorization servers MUST support PKCE and prevent downgrade.
Read the updated RFC section ↗Redeem a code, then use the token.
- The client sends response_type=code, client_id, and the relevant redirect and transaction parameters.
- The code is bound to the client and redirect; it MUST be used only once and expires shortly after issuance.
- The client authenticates when required and exchanges the code for access and optional refresh tokens.
This chapter shows the original framework. Use the later PKCE and injection protections for current deployments.
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