According to the OAuth 2.0 core specification, all OAuth clients must be registered with the OAuth authorization server and obtain a client identifier before any interactions. The aim of the Dynamic Client Registration OAuth 2.0 profile is to expose an endpoint for client registration in a standard manner to facilitate on-the-fly registrations.
The Dynamic Client Registration OAuth 2.0 profile is available at https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg.
The dynamic-registration endpoint exposed by the authorization server can be secured or not. If it’s secured, it can be secured with OAuth, HTTP Basic Authentication, Mutual TLS, or any other security protocol as desired by the authorization server. The Dynamic Client Registration profile doesn’t enforce any authentication protocols over the registration endpoint, but it must be secured with TLS. If the authorization server decides that it should allow the endpoint to be public and let anyone be registered, it can do so.
To register a client, it must pass all its metadata to the registration endpoint. Following lists out only a subset of the request attributes. In addition to these, the profile also has the provision to introduce your custom attributes as well.
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: authz.server.com
{
"redirect_uris":["https://client.org/callback","https://client.org/callback2"],
"token_endpoint_auth_method":"client_secret_basic",
"grant_types": ["authorization_code" , "implicit"],
"response_types": ["code" , "token"],
}
Let’s have a look at the definition of each parameter.
redirect_uris: An array of URIs under the control of the client. The user is redirected to one of these redirect_uris after the authorization grant.
token_endpoint_auth_method: The supported authentication scheme when talking to the token endpoint. If the value is client_secret_basic, the client sends its client ID and the client secret in the HTTP Basic Authorization header. If it’s client_secret_post, the client ID and the client secret are in the HTTP POST body. If the value is none, the client doesn’t want to authenticate, which means it’s a public client (as in the case of the OAuth Implicit grant type).
grant_types: An array of grant types supported by the client.
response_types: An array of expected response types from the authorization server.
Based on the policies of the authorization server, it can decide whether it should proceed with the registration. Even if it decides to go ahead with the registration, the authorization server need not accept all the suggested parameters from the client. For example, the client may suggest using both authorization_code and implicit as grant types, but the authorization server can decide what to allow. The same is true for the token_endpoint_auth_method: the authorization server can decide what to support.
The following is a sample response from the authorization server:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id":"iuyiSgfgfhffgfh",
"client_secret": "hkjhkiiu89hknhkjhuyjhk",
"client_id_issued_at":2343276600,
"client_secret_expires_at":2503286900,
"redirect_uris":["https://client.org/callback", "https://client.org/callback2"],
"grant_types": "authorization_code",
"token_endpoint_auth_method": "client_secret_basic"
}
Let’s have a look at the definition of each parameter.
client_id: A generated unique identifier for the client.
client_secret: The generated client secret corresponding to the client_id. This is optional. For the Implicit grant type, client_secret isn’t required.
client_id_issued_at: The number of seconds since January 1, 1970.
client_secret_expires_at: The number of seconds since January 1, 1970.
redirect_uris: Accepted redirect_uris.
token_endpoint_auth_method: The accepted authentication method for the token endpoint.
The Dynamic Client Registration OAuth 2.0 profile is extremely useful in mobile applications. Mobile client applications secured with OAuth have the client ID and the client secret baked into the application. These are the same for all installations for a given application. If a given client secret is compromised, that will affect all installations, and rogue client applications can be developed using the stolen keys. These rogue client applications can generate more traffic on the server and exceed the legitimate throttling limit, hence causing a denial of service attack. With dynamic client registration, you need not set the same client ID and client secret for all installations. During the installation process, the application can talk to the authorization server’s registration endpoint and generate a client ID and a client secret per installation.
More details and the applications of the OAuth 2.0 Dynamic Client Registrayion Profile are covered in my book Advanced API Security.
The Dynamic Client Registration OAuth 2.0 profile is available at https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg.
The dynamic-registration endpoint exposed by the authorization server can be secured or not. If it’s secured, it can be secured with OAuth, HTTP Basic Authentication, Mutual TLS, or any other security protocol as desired by the authorization server. The Dynamic Client Registration profile doesn’t enforce any authentication protocols over the registration endpoint, but it must be secured with TLS. If the authorization server decides that it should allow the endpoint to be public and let anyone be registered, it can do so.
To register a client, it must pass all its metadata to the registration endpoint. Following lists out only a subset of the request attributes. In addition to these, the profile also has the provision to introduce your custom attributes as well.
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: authz.server.com
{
"redirect_uris":["https://client.org/callback","https://client.org/callback2"],
"token_endpoint_auth_method":"client_secret_basic",
"grant_types": ["authorization_code" , "implicit"],
"response_types": ["code" , "token"],
}
Let’s have a look at the definition of each parameter.
redirect_uris: An array of URIs under the control of the client. The user is redirected to one of these redirect_uris after the authorization grant.
token_endpoint_auth_method: The supported authentication scheme when talking to the token endpoint. If the value is client_secret_basic, the client sends its client ID and the client secret in the HTTP Basic Authorization header. If it’s client_secret_post, the client ID and the client secret are in the HTTP POST body. If the value is none, the client doesn’t want to authenticate, which means it’s a public client (as in the case of the OAuth Implicit grant type).
grant_types: An array of grant types supported by the client.
response_types: An array of expected response types from the authorization server.
Based on the policies of the authorization server, it can decide whether it should proceed with the registration. Even if it decides to go ahead with the registration, the authorization server need not accept all the suggested parameters from the client. For example, the client may suggest using both authorization_code and implicit as grant types, but the authorization server can decide what to allow. The same is true for the token_endpoint_auth_method: the authorization server can decide what to support.
The following is a sample response from the authorization server:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id":"iuyiSgfgfhffgfh",
"client_secret": "hkjhkiiu89hknhkjhuyjhk",
"client_id_issued_at":2343276600,
"client_secret_expires_at":2503286900,
"redirect_uris":["https://client.org/callback", "https://client.org/callback2"],
"grant_types": "authorization_code",
"token_endpoint_auth_method": "client_secret_basic"
}
Let’s have a look at the definition of each parameter.
client_id: A generated unique identifier for the client.
client_secret: The generated client secret corresponding to the client_id. This is optional. For the Implicit grant type, client_secret isn’t required.
client_id_issued_at: The number of seconds since January 1, 1970.
client_secret_expires_at: The number of seconds since January 1, 1970.
redirect_uris: Accepted redirect_uris.
token_endpoint_auth_method: The accepted authentication method for the token endpoint.
The Dynamic Client Registration OAuth 2.0 profile is extremely useful in mobile applications. Mobile client applications secured with OAuth have the client ID and the client secret baked into the application. These are the same for all installations for a given application. If a given client secret is compromised, that will affect all installations, and rogue client applications can be developed using the stolen keys. These rogue client applications can generate more traffic on the server and exceed the legitimate throttling limit, hence causing a denial of service attack. With dynamic client registration, you need not set the same client ID and client secret for all installations. During the installation process, the application can talk to the authorization server’s registration endpoint and generate a client ID and a client secret per installation.
More details and the applications of the OAuth 2.0 Dynamic Client Registrayion Profile are covered in my book Advanced API Security.