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.
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 and the client_secret are equivalent to a username and password for a user.
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:
Before initiating any protocol, the client registers with the authorization server (typically through a form) to:
For example, registration can be accomplished:
When registering a client, the client developer SHALL:
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.