The term client does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
Client Id (Identifier)
The client_id is a public identifier for apps.
After the registration, the authorization server issues the registered client a client identifier (known as the client id) – a unique string representing the registration information provided by the client.
The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server.
The client identifier string size is left undefined by the Oauth specification but many application uses a 32-character hex string
The client should avoid making assumptions about the identifier size.
The authorization server SHOULD document the size of any identifier it issues.
It should be at minimum guessable (ie generated randomly)
The client secret is a secret equivalent to a password.
To generate a secure secret, you can generate randomly a 256-bit value and converting it to a hexadecimal representation.
It should be kept secret.
In a native app, it is a difficult issue. Therefore, the spec requires the provider to not treat native app client secret as confidential. See RFC 6749, parts 9 and 10 and RFC 8252, part 8 (note part 8.5)
OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):
|Type||Confidential credentials||Client Authentication||eg||Profiles|
|confidential (private)||Yes||secure|| - client implemented on a secure server with restricted access to the client credentials |
- or capable of secure client authentication using other means
|web server based application|
|public||No||Unsecure|| Clients executing on the device used by the resource owner, |
and incapable of secure client authentication via any other means.
| - an installed native application
- or a web browser-based application
This specification has been designed around the following client profiles:
- establish trust
- obtain the required client properties (e.g., redirection URI, client type).
For example, registration can be accomplished:
- using a self-issued or third-party-issued assertion,
- or by the authorization server performing client discovery using a trusted channel.
When registering a client, the client developer SHALL:
- specify the client type
- provide its client redirection URIs
- include any other information required by the authorization server (e.g., application name, website, description, logo image, the acceptance of legal terms).
The authorization server MUST require the following clients to register their redirection endpoint:
The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint.
Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as an open redirector as described in Section 10.15.