Two endpoints, two channels
03The browser requests permission. The client exchanges grants at the token endpoint.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 3 ↗
RFC 6749 · § 3EXAMPLE
3 / 3
03
Use a separate token request.
The client calls the token endpoint directly.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 3.1.2RFC 9700 § 2.1
The BCP requires exact redirect matching, with the native localhost-port exception, and forbids open redirectors.
Read the updated RFC section ↗Do not confuse authorization with token exchange.
- The authorization endpoint interacts with the resource owner; the token endpoint issues tokens from a grant.
- Redirect destinations and response_type select how the authorization response returns.
- The token endpoint uses POST and TLS; client authentication depends on client type and grant.
The drawing groups logical endpoints; they may live on the same authorization server.
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