Every time a new application needs to connect to your API, someone has to register it. Create the OAuth client, assign credentials, configure scopes, record the registration. When you have five partners, this is a fifteen-minute task. When you have fifty, it's a job.

Dynamic Client Registration (DCR) eliminates that manual step. Instead of a person creating OAuth clients one at a time, applications register themselves through a standardized API endpoint. The registration, credential issuance, and initial configuration happen automatically.

That sounds like it solves the problem. It doesn't, entirely. DCR automates registration. It doesn't automate governance. And in regulated industries like healthcare and financial services, registration without governance is just faster chaos: more applications getting access more quickly, with less visibility into who has what and why.

This guide explains what DCR is, how it works, where it came from, what it solves, and what it leaves unsolved.

What Is Dynamic Client Registration?

Dynamic Client Registration is a protocol defined in RFC 7591 that allows OAuth 2.0 clients to register with an authorization server programmatically. Instead of an administrator manually creating a client entry in the authorization server, the client application sends a registration request to a dedicated endpoint and receives its credentials in the response.

In plain terms: the application tells your system "here's who I am and what I need," and your system responds with "here are your credentials and what you're allowed to do." No human in the loop unless you want one.

The companion specification, RFC 7592, adds the ability for clients to update or delete their own registrations after the initial setup. Together, these two specs define the full lifecycle: register, update, and deregister, all through API calls.

How DCR Works

The registration flow has four steps:

The application sends a registration request. The request includes metadata about the application: its name, the redirect URIs it uses, the grant types it supports, the scopes it's requesting, and optionally a software statement (a signed JWT that verifies the application's identity). This request goes to your authorization server's registration endpoint.
The authorization server validates the request. Your server checks the metadata against your policies. Are the requested scopes allowed? Are the redirect URIs valid? If you require software statements, is the signature valid? You control the validation rules.
The server creates the client and returns credentials. If the request passes validation, the server creates an OAuth client entry and returns a client ID, a client secret (if applicable), and the registration metadata as confirmed by the server. This response is immediate.
The application uses the credentials. The application stores its credentials and uses them to request access tokens through the standard OAuth 2.0 flows. From this point forward, the application behaves like any other registered client.

The entire flow happens through API calls. No portal login, no email to your team, no Jira ticket.

Manual Registration vs. DCR

To understand why DCR matters, compare it to how most API programs register clients today.

Manual registration

Partner contacts your team (email, form, Slack)
Someone on your team creates an OAuth client in your authorization server
Credentials are generated and sent to the partner (often over email)
Scope configuration is done manually, sometimes by a different person
The registration is recorded in a spreadsheet, ticket, or wiki page
Elapsed time: hours to days, depending on who's available

Dynamic Client Registration

Partner's application sends a registration request to your DCR endpoint
Your authorization server validates the request against your policies
Credentials are returned in the API response
Scopes are assigned based on the request and your policy rules
The registration is recorded automatically in your authorization server
Elapsed time: seconds

The difference isn't just speed. It's consistency. Every registration follows the same validation rules. Every client gets credentials through the same process. There's no variation based on who handles the request, which day of the week it arrives, or whether the person who usually does this is on vacation.

Where DCR Comes From

DCR was originally standardized by the IETF (Internet Engineering Task Force) in RFC 7591, published in 2015. It was designed to solve a general problem: how do you register OAuth clients at scale without manual intervention?

The specification gained significant traction in two regulated industries:

Open banking. The UK's Open Banking Implementation Entity adopted DCR as part of its standard in 2018. When the regulation required banks to allow third-party financial applications to access customer accounts, manual registration wasn't viable. Hundreds of fintech companies needed to register with dozens of banks. DCR made that possible without each bank manually processing each registration.

Healthcare. As CMS-0057-F and the ONC Cures Act push healthcare organizations toward standardized FHIR APIs, DCR is becoming the expected mechanism for third-party application registration. When a health plan needs to support dozens of patient-facing apps, provider-facing tools, and payer-to-payer connections, manual registration doesn't scale. SMART on FHIR authorization combined with DCR is the pattern regulators and implementers are converging on.

The common thread: whenever a regulated industry mandates that organizations open their APIs to third parties, DCR becomes necessary to handle the volume.

Why DCR Matters for API Programs

DCR isn't just a protocol convenience. It changes how your API program operates in three ways.

It removes the registration bottleneck

In most API programs, onboarding speed is limited by manual steps. Credential provisioning is one of the most common bottlenecks. If a partner can't get credentials until someone on your team processes a request, every onboarding timeline includes a wait. DCR eliminates that wait. Partners get credentials the moment they register, not the moment someone gets to their ticket.

It creates a system of record automatically

When clients register through DCR, the registration metadata is captured in your authorization server, not in a spreadsheet or an email thread. Every client has a record of when it registered, what it requested, and what it was granted. That record is queryable, auditable, and current. When an auditor asks "which applications have access to your APIs?", you can answer from your system, not from a document someone last updated three months ago.

It enables policy-based access control

With manual registration, access control is a human judgment call every time. With DCR, you encode your policies into the validation logic. Applications from approved software vendors get registered automatically. Applications requesting sensitive scopes get routed to an approval queue. Applications that don't meet your criteria get rejected with a clear error. The policy is consistent because it's code, not a person's interpretation of a guideline.

DCR and SMART on FHIR

In healthcare, DCR and SMART on FHIR work together. SMART on FHIR defines the authorization model: how applications request scopes, how patients consent to data access, and how tokens are issued. DCR defines how applications register with the authorization server in the first place.

Without DCR, every SMART on FHIR application registration is manual. The application developer emails your team, your team creates the OAuth client, assigns the requested scopes, and sends back credentials. Multiply that by the number of applications that need to connect as CMS-0057-F compliance drives more third-party integrations, and manual registration becomes the bottleneck that slows your entire compliance timeline.

With DCR, applications register programmatically, declare their scope requirements upfront, and receive credentials immediately (or after automated policy checks). The registration itself becomes a governed, auditable process rather than an ad-hoc administrative task.

When to Implement DCR

DCR makes sense when:

You're onboarding more than a handful of new applications per quarter
Manual registration is delaying partner onboarding
You need an auditable record of every client registration for compliance
You're in a regulated industry (healthcare, financial services) where standardized registration is expected
You're building a self-service developer portal where partners manage their own applications

DCR doesn't make sense when you have a small, stable set of partners that rarely changes. If you register two new clients a year, the overhead of implementing DCR exceeds the benefit. But if your partner base is growing, and especially if regulation is driving that growth, DCR is the mechanism that keeps registration from becoming the constraint.

What DCR Doesn't Solve

DCR is a registration protocol. It gets applications credentialed fast. But registration is the first five minutes of a relationship that lasts months or years. Everything that comes after registration is where compliance lives, and DCR has nothing to say about it.

Scope governance. DCR lets an application request scopes and receive them if your validation rules allow it. But who reviews whether those scopes are still appropriate six months later? Who notices when an application's use case has changed but its scopes haven't? DCR handles the initial grant. It doesn't handle the ongoing review.

Approval workflows. In regulated industries, not every registration should be auto-approved. A patient-facing app requesting access to clinical notes should go through a human review. DCR can route requests based on policy, but the approval workflow, the reviewer assignment, the recorded justification, all of that lives outside the protocol.

Lifecycle management. Applications get registered. Then what? DCR doesn't track whether an application is still active, whether the developer organization still has a valid agreement, or whether credentials should have been rotated or revoked. The full lifecycle, from registration through monitoring to deactivation, requires a management layer that DCR doesn't provide.

Audit reporting. DCR creates a registration record in your authorization server. But auditors don't just want to know that an application registered. They want to know who approved the scope grant, when the last access review was conducted, whether any scopes were modified since registration, and whether revoked applications are actually revoked. That's a governance trail, not a registration log.

The pattern is clear: DCR solves the speed problem. It does not solve the governance problem. For API programs subject to CMS-0057-F, open banking regulations, or any framework that requires auditable access control, DCR is a necessary component but not a sufficient one. You need the registration protocol and a governance layer that manages everything around it.

Getting Started

If you're evaluating DCR for your API program, start by looking at where registration friction lives today. How long does it take a new partner to get credentials? How many people are involved? Where's the record of what was granted?

If the answers involve "it depends," "someone on the team handles it," or "check the spreadsheet," you have the use case for DCR. But don't stop there. Ask the harder questions: What happens after registration? Who reviews scope grants? How do you know which applications are still active? If those answers are equally vague, you need more than a registration protocol. You need a governance layer.

Apiable provides that layer. Applications register through DCR or self-service, and Apiable orchestrates what happens next: scope validation against your policies, approval workflows for sensitive access, ongoing lifecycle management, and audit logging across the full application lifecycle. DCR handles the front door. Apiable manages the building. Book a demo to see how it works.

What Is Dynamic Client Registration — And Why Does It Matter?