Implicit grant: historical behavior
05The original framework allowed the authorization response itself to deliver an access token.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.2 ↗
RFC 6749 · § 4.2EXAMPLE
3 / 3
03
A leaked token can be replayed.
Use the later code-flow recommendation when building new clients.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 4.2RFC 9700 § 2.1.2
The security BCP discourages access tokens in authorization responses and recommends responses that issue tokens at the token endpoint instead.
Read the updated RFC section ↗Read this flow as history, not a deployment recommendation.
- Originally, response_type=token returned an access token in the redirect fragment.
- The implicit grant does not use a code exchange or issue refresh tokens in this flow.
- Current guidance in RFC 9700 says clients SHOULD NOT use this pattern unless injection and leakage are mitigated.
The old text remains published. Later guidance changes how it should be deployed.
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