Dynamic Client Registration Management

Dynamic Client Registration (DCR) allows for a client application to self-register a client with an OAuth server. This OpenID specification outlines the protocol for how DCR works. We also overview DCR in our articles Understanding DCR and Using DCR.

As outlined by RFC-7592, you can use a CRUD-API to manage dynamically registered clients. When enabled, the metadata returned as part of the client registration will contain a Registration Access Token and an endpoint to manage the given client. The endpoint is bound to the specific client and can only perform management on that particular client.

The Curity Identity Server also features a capability to request a dcrm scope to provide an access token to manage any dynamically registered client.

DCR Self-Management

The registration response below (truncated for readability) lists the registration_client_uri. This is the endpoint that manages this specific client. Note that the end of that endpoint is, in fact, the actual client_id of the dynamically registered client.

The response also contains the registration_access_token used to access the endpoint and perform the management tasks that the endpoint allows. The allowed methods are GET (Read), PUT (Update), and DELETE (Delete).

A DELETE request would obviously delete the client. In terms of executing a DELETE request, the default access token has a Time To Live (TTL) of 365 days.

A GET or PUT request would automatically rotate the registration_access_token, invalidate the current token, and provide a new one in the response metadata. In addition to rotating the token, a request automatically rotates the client_secret, and just like with the token, provides a new secret in the metadata response.

{
    ...
    "registration_client_uri": "https://idsvr.example.com/token-service/oauth-registration/c2736523-5624-4d3b-b141-b44533d07c78",
    "registration_access_token_expires_in": 31536000,
    "registration_access_token": "9f24e7fb-8600-43df-b414-c448613b5e4e",
    "client_id": "c2736523-5624-4d3b-b141-b44533d07c78",
    "client_secret_expires_at": 0,
    "client_id_issued_at": 1602011280,
    "client_secret": "SbFEedMlUCm2rhKtaZ7eLwiTNBjfzILWnAUlvXRzh6k",
    ...
}

Performing a GET request would return the client metadata and simultaneously rotate both the client_secret and registration_access_token — provided that the access token is valid. By default, the TTL is 28 days for GET and UPDATE requests, but you can configure it differently.

In the example below, we use a PUT request with cURL to update a client's redirect_uris.

curl -Ss -X PUT \
https://idsvr.example.com/token-service/oauth-registration/c2736523-5624-4d3b-b141-b44533d07c78 \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer 9f24e7fb-8600-43df-b414-c448613b5e4e' \
--data-raw '{
    "client_id": "c2736523-5624-4d3b-b141-b44533d07c78",
    "redirect_uris": [
        "https://localhost/callback-new"
    ]
}'

DCRM With Client Certificates

You can configure the authentication method for DCR to use mutual-tls or mutual-tls-by-proxy. In such cases, a client certificate is used when registering a dynamic client through the registration endpoint, and the registration_access_token is bound to the client certificate.

It is also possible to configure things so that whenever this token is used to authorize any management requests for the dynamic client, the same client certificate must be used for authentication. This option is not enabled by default. Use this when the validity of the client certificate is longer than the client’s dynamic registration.

Manage Any Dynamically Registered Client

The previous section describes how a dynamically registered client can manage itself. However, the Curity Identity Server can also issue an Access Token with a dcrm scope. This token can manage any dynamically registered client.

Since the token is not a registration_access_token, it can be used until it expires or is revoked. This means that the token does not automatically rotate when making a GET or PUT call. Here, the capabilities (Read, Update, Delete) are the same as for self-management.

Summary

Dynamically registered clients can manage themselves through a CRUD-like API. With self-management, the client_secret and registration_access_token rotates with GET and PUT requests, and new details are provided in the metadata response for each of those requests. It is also possible to allow a configured client to issue Access Tokens with the dcrm scope to manage any dynamically registered client.

For more information on DCRM in the Curity Identity Server, refer to the product documentation.

This article has been updated on: 2023-03-24Published: 2023-03-24

Jonas Iggbom

Director of Sales Engineering at Curity