What is Dynamic Client Registration (DCR)? The key to scalable OAuth 2.0

In API security, the way we onboard new applications hasn’t really changed for years and it’s starting to show its limits. For years, developers have relied on manual developer portals to generate a client_id and client_secret. While this works for internal apps, it becomes a massive bottleneck for open ecosystems like Open Banking or large-scale SaaS platforms.

The solution is Dynamic Client Registration (DCR).

Defined in RFC 7591, DCR moves client onboarding from a manual administrative task to an automated, programmatic protocol. This article explores how DCR works, why it is essential for modern API security, and how to implement it safely using Software Statement Assertions (SSA).

What is Dynamic Client Registration?#

Dynamic Client Registration (DCR) is a protocol that allows an OAuth 2.0 client application to register itself with an Authorization Server via a REST API, rather than requiring a developer to fill out a web form manually.

When a DCR request is successful, the Authorization Server immediately issues the client credentials (Client ID and Client Secret) and registers the necessary metadata (such as Redirect URIs and Grant Types).

Note: DCR is strictly defined in IETF RFC 7591, ensuring interoperability across different identity providers.

How the DCR flow works#

The DCR process is a synchronous API exchange that typically follows these three steps:

1. Discovery#

Before registering, the client usually queries the Authorization Server’s OpenID Connect Discovery endpoint (/.well-known/openid-configuration). This JSON response tells the client where the registration_endpoint is located.

2. The registration request#

The client application sends a POST request to the registration endpoint. The body of this request is a JSON object containing the client's metadata.

Example DCR Payload:

JSON

3. The credentials response#

If the metadata is valid, the server responds with HTTP 201 (Created) and the new credentials. The client can now immediately start an OAuth 2.0 authorization flow.

In simple terms:

An app asks the auth server for a client_id at runtime.

No UI.

No copy-paste.

No human in the loop.

Why use Dynamic Client Registration?#

Moving from manual to dynamic registration offers three major competitive advantages:

• Infinite Scalability: DCR is critical for ecosystems with thousands of Third-Party Providers (TPPs).6 It removes the human bottleneck of approving every single app integration.
• CI/CD Automation: DevOps teams can use DCR to spin up ephemeral client credentials for automated testing pipelines and then discard them, improving security hygiene.
• Standardization: It enforces a strict JSON schema for client metadata, reducing configuration errors caused by manual data entry.

Securing DCR: Open vs. Protected registration#

A common concern with DCR is security. If you leave your registration endpoint "open," anyone can create a client ID. To prevent abuse, DCR is typically implemented in two modes.

1. Open Dynamic Registration#

In this mode, the endpoint is public. This is rarely recommended for sensitive APIs but may be used for public social apps where low-security barriers are desired.

2. Protected Dynamic Registration (Recommended)#

This mode requires the caller to prove their identity before they can register. There are two standard methods for this:

A. Initial Access Token (IAT)#

The developer must first obtain a specialized "Initial Access Token" from an admin console. This token allows them to call the registration endpoint once. This is secure but still requires a manual "handshake" to get the token.

B. Software Statement Assertions (SSA)#

This is the Gold Standard for high-security environments like Open Banking and PSD2.

1. The Client obtains a digitally signed JWT (JSON Web Token) called a Software Statement Assertion (SSA) from a trusted Central Authority (e.g., a regulator or governance body).
2. The Client submits this SSA to the Authorization Server's DCR endpoint.
3. The Server cryptographically verifies the SSA's signature. If valid, the server knows the client has been vetted by the Central Authority and issues the credentials.

The future of API onboarding#

Dynamic Client Registration is no longer just a "nice-to-have", it is the backbone of the modern, interoperable web. By implementing RFC 7591 and leveraging Software Statement Assertions, organizations can build API platforms that are both open to innovation and closed to security threats.

If your organization is planning to scale its API ecosystem or enter the Open Finance space, implementing DCR is the first step toward automation and trust.

Key Takeaways#

• DCR (RFC 7591) allows apps to register via API, bypassing manual portals.
• It is essential for Open Banking and large partner ecosystems.
• Discovery endpoints are used to find the registration URL dynamically.
• Secure your DCR endpoint using Initial Access Tokens or Software Statements (SSAs) to prevent spam and abuse.