Refresh without another prompt
09A refresh token returns to the authorization server, never to the resource server as an access credential.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 6 ↗
RFC 6749 · § 6EXAMPLE
4 / 4
04
Use the access token at the API.
Do not send refresh tokens to resource servers.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 6RFC 9700 § 4.14
Public-client refresh tokens must be sender-constrained or rotated to detect replay. Rotation invalidates the previous token and retains its relationship.
Read the updated RFC section ↗Keep renewal authority at the token endpoint.
- The client sends grant_type=refresh_token and authenticates when required.
- Requested scope cannot exceed the scope originally granted.
- If the server returns a new refresh token, the client discards the old one and replaces it.
The 2012 framework allowed refresh-token replacement. The later BCP makes replay protection a requirement for public-client refresh tokens.
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