About
authentication method for a client in Oauth.
The client MUST NOT use more than one authentication method in each request.
Usage
Client authentication is used for:
- Enforcing the binding of refresh tokens and authorization codes to the client they were issued to. Client authentication is critical when an authorization code is transmitted to the redirection endpoint over an insecure channel or when the redirection URI has not been registered in full.
- Recovering from a compromised client by disabling the client or changing its credentials, thus preventing an attacker from abusing stolen refresh tokens. Changing a single set of client credentials is significantly faster than revoking an entire set of refresh tokens.
- Implementing authentication management best practices, which require periodic credential rotation. Rotation of an entire set of refresh tokens can be challenging, while rotation of a single set of client credentials is significantly easier.
By Client Type
Confidential Client
If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server.
The authorization server MAY accept any form of client authentication meeting its security requirements.
Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g.:
Public Client
The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
Requirement
The requirements are based:
- on the client type
- and on the authorization server policies.
Method
Password Authentication
The authorization server MUST require the use of TLS as described when sending requests using password authentication.
Since this client authentication method involves a password, the authorization server MUST protect any endpoint utilizing it against brute force attacks.
Basic
Clients in possession of a client password MAY use the HTTP Basic authentication scheme to authenticate with the authorization server where:
- the username is the client identifier
- the password is the password
They must be both encoded using the application/x-www-form-urlencoded encoding algorithm per Appendix B
For example, the header authorization:
Authorization: Basic <credentials>
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
request-body
Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes).
The authorization server MAY support including the client credentials in the request-body using the following parameters:
- client_id - REQUIRED. The client identifier
- client_secret - REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string.
The parameters can only be transmitted in the request-body and MUST NOT be included in the request URI.
For example, a request to refresh an access token using the body parameters (with extra line breaks for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
Others
Any suitable HTTP authentication that the the authorization server support can also be used.