Dynamic Client Registration (DCR)

Introduction

Before an application can participate in OAuth and OpenID Connect grant type flows, it must be registered with the OIDC Provider as a Client. During this registration, the application will be allocated a client identifier or client_id and (optionally) a client_secret. These are used when calling OAuth endpoints. When a client makes a request to the client registration endpoint, it must provide the following:

Authorization tokens, such as a software statement assertion, as required by the OIDC Provider
Client metadata that contains the client information

When the registration request is processed, the OIDC Provider can perform the following actions:

Set default values for Client properties that are not specified. For example, if the client metadata does not specify grant_types, then the OIDC Provider may set a default value, such as authorization_code.
Override Client properties that are enforced or not supported. For example, the OIDC Provider may be configured to require that all clients use a stronger form of client authentication, such as private_key_jwt.
Require the use of authorization tokens, such as software statement assertions, and specific netadata values dictated by security profiles, such as Financial Grade API (FAPI).

Therefore, when a dynamic client is created, the Client configuration stored may not match the contents of the client metadata. When the client has been registered, the OIDC Provider may be configured to respond with a registration access token that can be used to subsequently manage the client. The dynamic client registration specification is RFC 7591 and management specification is RFC 7592.

Software Statement Assertions

While the OAuth 2.0 DCR specification does not enforce the usage of software statement assertions to authorize a registration request, it is prescribed to be used for stricter security profiles, such as Financial Grade API (FAPI).

The software statement assertion is a JSON Web Token (JWT) that is signed using pre-registered keys. The OIDC Provider validates the assertion by retrieving the public keys from a published endpoint called the jwks_uri. Certain security profiles may require this to be a centrally governed endpoint. For example, the UK Open Banking standards require Clients to obtain a Software Statement key from a certain governing body called the Open Banking Directory. The directory hosts the jwks_uri.

Client metadata payload

The client metadata contains the properties of a Client. This is usually in the form of a JSON payload. However, an extension to the specification is adopted by certain specialized security profiles, such as Australia's CDR, that requires a signed JSON Web Token.

Recipes or Security Profiles

Several regulatory bodies prescribe the use of specific methods of authorizing client registration and management, and the contents of the client metadata. Security Profiles in IBM Security Verify Access enforce these requirements when configured on the OIDC Provider settings. Details about the recipies can be found in the DCR task topic.