Public and confidential clients
02An app’s ability to keep credentials confidential determines its client type.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 2.1 ↗
RFC 6749 · § 2.1EXAMPLE
3 / 3
03
Treat installed apps according to their actual capabilities.
A distributed app does not become confidential merely because it contains a string called a secret.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 2.1RFC 8252 § 8.5
Native-app guidance explicitly rejects treating a shared embedded secret as proof of the app’s identity.
Read the updated RFC section ↗A client ID is not a secret.
- Register the client before starting the flow, subject to the deployment’s registration model.
- Confidential clients can protect credentials; public clients cannot. A client may have distributed components with different security contexts.
- Client identifiers identify registrations and MUST NOT be used alone as authentication.
A secret copied into every installed app cannot establish the identity of an individual installation.
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