OAuth 2.0 Dynamic Client Registration Management (DCRM) Protocol

3 min readApr 17, 2017

When a client gets registered through OAuth 2.0 Dynamic Client Registration at the authorization server, the client’s registration should be managed during the lifetime of the client. The rules to manage client registration is defined by the DCRM protocol.

Let’s get an idea on the flow of the DCRM protocol.

The protocol talks about three methods to manage client registration at the authorization server.

Query the current registration state of the client
Update the registration of the client
Delete the client

In order to perform the above actions, there should be an interaction between the client and the authorization server. The flow of the DCRM protocol can be illustrated as below,

Client Configuration Endpoint: Protected resource of OAuth 2.0 to manage the registration information of a registered client at the authorization server. The URL will be returned to the client during the registration. It basically combines the URL of Client Registration Endpoint and the Client-identifier.

Any DCRM request from the client should contain the registration access token which is bound to the client identifier. The initial registration access token would be returned in the client information response from the client registration endpoint at the authorization server. If the client receives a different registration access token in any response from the client configuration endpoint, then the client should replace the old registration access token by the new one. All the request from the client to Client Configuration Endpoint should be authenticated by the registration access token.

Read Request

The client makes an HTTP GET request to the Client Configuration Endpoint to read the current registration state of the client.

Example request:

Update Request

The client makes an HTTP PUT request to the Client Configuration Endpoint of the authorization server to update a previously registered client.

This request should include all client metadata returned in the previous Client Information Response except the following,

registration_access_token
registration_client_uri
client_secret_expires_at
client_id_issued_at

The values in the update request should fully replace the previous registration information of the client. The fields which are not specified in the request should be filled with null values by the server.

Example request:

Client Information Response for Read/Update Request

If the read/update is successful at the authorization server then the response contains,

HTTP 200 OK
Content type : “application/json”
Return all the registered metadata of the client and the client credentials.
May replace any invalid values in the metadata field with suitable default values

If the client does not exist in the server, then the response will be:

HTTP 401 Unauthorized

If the client does not have permission to read its record, then the response will be:

HTTP 403 Forbidden

If the registration access token is not valid

HTTP 401 Unauthorized
Error : invalid_token

Delete Request

The client makes an HTTP DELETE request to the Client Configuration Endpoint of the authorization server to delete itself.

Example Request:

Delete Confirmation Response

If the client has been successfully unregistered, Invalidate the client_id, client_secret and the registration access token in the server. The response would be:

HTTP 204 No Content

If the server does not support the deletion,

HTTP 405 Not Supported

If the client does not exist on the server,

HTTP 401 Unauthorized

If the client does not have permission to read its record,

HTTP 403 Forbidden