About
client is one of the 4 roles of the Oauth specification.
In its most basic form, it's a web site used by a end-user.
In more details, it's is a (first-party or third party service application making protected resource requests on behalf of the resource owner (end-user) and with its authorization.
Example
- An end-user (resource owner) can grant
- a printing service (the client) access to her protected photos
- stored at a photo-sharing service (resource server).
Implementation
The term client does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
Properties
Credential
client_id and the client_secret are equivalent to a username and password for a user.
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)
Client Secret
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)
Type
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 |
Profile
This specification has been designed around the following client profiles:
Management
Registration
Before initiating any protocol, the client registers with the authorization server (typically through a form) to:
- 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:
- Confidential clients utilizing the implicit grant type.
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.