Authenticate the client
06When credentials can be issued and kept confidential, require the app to prove its own identity.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 2.5 ↗
RFC 9700 · § 2.5EXAMPLE
3 / 3
03
Validate the proof.
The server verifies the registered credential before accepting the client authentication.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 2.3RFC 9700 § 2.5
Where client authentication is feasible, the BCP recommends asymmetric methods such as mTLS and private_key_jwt.
Read the updated RFC section ↗Prefer asymmetric client authentication.
- Servers SHOULD enforce client authentication where credential registration and confidentiality are feasible.
- Asymmetric methods such as mTLS and private_key_jwt are RECOMMENDED.
- Public clients cannot safely rely on a distributed, embedded client secret.
With asymmetric authentication, the authorization server need not retain a shared symmetric secret. PKCE still addresses transaction binding and is recommended for confidential clients.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
PrivacyAll chapters in this RFC
- OAuth overview
- Authorization code + PKCE
- Retire unsafe grants
- Prevent token replay
- Limit token privileges
- Authenticate the client
- Metadata, TLS & CORS
- The attacker model
- Redirect URI validation
- Referer header leakage
- Browser history leakage
- Authorization server mix-up
- Authorization code injection
- Access token injection
- Cross-site request forgery
- PKCE downgrade
- Leakage at resource servers
- Misuse of stolen tokens
- Open redirection
- 307 credential forwarding
- TLS termination & proxies
- Refresh token protection
- Client as resource owner
- Clickjacking
- In-browser messaging