Using Dynamic Client Registration

Dynamic Client Registration allows new clients to be registered using a standard API. For more details about the architectural structure of DCR see DCR Explained

The Curity Solution

Curity provides the full benefits of OAuth and OpenID Connect standards, but also offers additional functionality to combat the risk for scope explosion.

There is also special handling of claims and scopes, such as mapping claims to specific clients and custom groupings that allow for greater flexibility and a more manageable architecture.

More information

For more information, see the mentioned articles above, or the Curity Developer Portal

Initial Access Token

In order to be able to register a new client in the Curity Identity Server, an Initial Access Token is needed. This is a token with the dcr scope. This token can only be used once. There are multiple ways to obtain an initial access token. Either using the client credentials flow or a user interactive flow such as the code flow, implicit flow or the assisted token flow. It can also be provided to the application out of band using any appropriate mechanism.

This overview will not explain in detail how to obtain the token, but will focus on how to register the client once the token is obtained.

Client Registration

With an initial access token in hand, the client can register itself. To do so, it will make an API call to Curity's Dynamic Client Registration endpoint. This endpoint is protected and requires an OAuth access token to be presented in the Authorization request header using the bearer authentication scheme (per RFC 6750). What is included in the request body depends on how dynamic clients are registered:

1. As instances of existing clients where the existing one functions as a sort of template for the dynamically registered one
2. As entirely new clients

These often correspond to the first two primary use cases described above but they need not.

Registration using Template Client

Dynamic clients can be based on an existing client that is configured to be a template. Registration of a new client that is to be based on another is also very easy; there is only one request parameter: software_id. This ID (as defined in RFC 7591) is the client ID of the template client. No other settings need to be included in the request, and, if there are any, Curity will ignore them. The settings are always taken from the template.

The values in the response are taken from template identified by the software_id input parameter. The client ID used for the software_id is only acceptable if that client is a template.

DCR Endpoint - Templatized Request

• Method: POST
• Agent: Backend
• Content Type: application/json
• Response Type: application/json

Request Parameters

A sample request is shown in the following listing:

POST /dcr HTTP/1.1
Host: localhost:8443
Authorization: Bearer 9e565e0b-a487-4092-a4af-461add3155f2
Content-Type: application/javascript
 
{ "software_id": "client-one" }

Registration using Non-templatized Client

Clients can also be registered without having to be based on an existing one. To register a client in this way, all metadata for that client must be included in the request.

DCR Endpoint - Non-Templatized Request

• Method: POST
• Agent: Backend
• Content Type: application/json
• Response Type: application/json

Request Parameters

Primary parameters

Additional parameters

Supported grant_types

The grant types supported depends on the configuration in the Curity Identity Server, but the possible values are:

Supported response_types

A sample request is shown in the following listing:

POST /dcr HTTP/1.1
Host: localhost:8443
Authorization: Bearer 9e565e0b-a487-4092-a4af-461add3155f2
Content-Type: application/javascript
{
	"scope": "openid read foo test_scope_1",
	"redirect_uris": [ "https://localhost:9000/cb" ],
	"grant_types": [ "authorization_code" ],
	"response_types": "code",
	"client_name": "monkey",
	"client_uri": "https://localhost:9000/",
	"tos_uri": "https://localhost:9000/tos",
	"default_max_age": 44
}

Response from the DCR Endpoint

Response

The response is a json document with the accepted values reflected back. If using templatized clients the response will contain the template's values.

Example

{
    "grant_types": [
        "authorization_code",
        "refresh_token",
        "implicit",
        "password"
    ],
    "subject_type": "public",
    "redirect_uris": [
        "https://localhost/client-one/cb1",
        "https://localhost/client-one/cb2"
    ],
    "client_id": "5bc6f48b-b3c4-413d-a374-20a77ffd1d59",
    "token_endpoint_auth_method": "client_secret_basic",
    "software_id": "client-one",
    "client_secret_expires_at": 0,
    "scope": "openid",
    "client_secret": "E4wYA0LOU7hQd-DDh6W2rrqP-OnSsj3pAk243a-j-oE",
    "client_id_issued_at": 1503067741,
    "client_name": "client-one",
    "response_types": [
        "code",
        "token",
        "id_token"
    ],
    "refresh_token_ttl": 3600,
    "id_token_signed_response_alg": "RS256"
}

Published: 2019-06-11

Jacob Ideskog

Identity Specialist and CTO at Curity