Password grant: now prohibited
06The original password grant passed resource-owner credentials through the client. Later guidance prohibits it.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.3 ↗
RFC 6749 · § 4.3EXAMPLE
3 / 3
03
More holders meant more possible leaks.
Current deployments must use an appropriate alternative grant.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 4.3RFC 9700 § 2.4
The password credentials grant changes from a narrowly permitted option in the framework to MUST NOT be used.
Read the updated RFC section ↗Do not implement this historical grant today.
- The 2012 grant used grant_type=password and directly exposed the owner’s credentials to the client.
- It was originally restricted to highly trusted scenarios when other grants were unavailable.
- RFC 9700 § 2.4 now states that the password credentials grant MUST NOT be used.
Keeping the old and new rules side by side makes the change visible without presenting the obsolete flow as safe.
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