What is Dynamic Client Registration?
Traditional OAuth typically involves a human manually pre-registering client services with host services. This approach isn’t ideal for AI applications: agentic work is unpredictable, often requiring dozens (or potentially hundreds) of MCP servers. Thankfully, a recent RFC by the IETF introduces an alternative approach: Dynamic Client Registration (DCR).
DCR is a protocol that specifies how OAuth clients could dynamically register with authorization servers, including authorization servers that they’ve never interacted with before. By using metadata fields, clients could safely authorize with servers at runtime without requiring a human present. Specifically, DCR streamlines client registration while allowing for the authorization server to decide any other requirements to authorize. With DCR, AI agents could connect with endless MCP servers at runtime; in such a context, it could be considered a Machine-to-Machine (M2M) mechanism.
Some aspects of DCR can be confusing to even seasoned developers. Technically, neither OAuth 2.1 nor OAuth 2.0 requires a human’s presence; it’s, however, the most conventional way to validate a client service. Likewise, DCR could involve a human if certain metadata is used that still requires human’s involvement. However, the general gist of DCR is that AI agents can request a client ID without a human clicking through screens, and DCR’s role is to provide standardized mechanics to make that happen. Some authors have compared this autopilot nature of DCR to a browser autofill equivalent for authorization. While a decent analogy, we believe that the best way to digest DCR is to more concretely break down how AI agents use it to accomplish tasks. Let’s dive in.
Quick Refresher: OAuth and MCP
A quick recap never hurts. For the junior developers that might be reading this, let’s revisit what OAuth, or Open Authorization, is. Additionally, let’s revisit the purpose of MCP, or Model Context Protocol.
What is OAuth?
OAuth is the leading standard of authorization on the web. Taking a step back, users have access to services. For example, a Stripe customer has a customer account—typically with an email and password—that they use to access the Stripe portal. It would be clunky and poor security to hardcode those credentials for third-party services to access their account on their behalf; instead machine access needs to be delegated, not impersonated.
OAuth fixes this by specifying how servers could issue access tokens linked to a user’s account to client services. This is typically a familiar process that requires a user to be present: you’ve likely clicked through an OAuth workflow (for example, using Google to sign-in to something).
What is MCP?
MCP, or Model Context Protocol, outlines a client-server relationship where the server provides a toolkit to client AI agents or LLMs. Unlike traditional APIs, MCP is significantly more prescriptive as it explicitly recommends to the AI process what it could do. Technically, MCP servers don’t mandate authorization, but when authorization is needed, OAuth 2.1 is required, and DCR is recommended over pre-registration. Additionally, most MCP servers do need authorization as they safeguard sensitive data and want to keep an active roster of clients.
Why does MCP need a client?
MCP mandates OAuth 2.1, which enforces Proof Key Code Exchange (PKCE), where a client must be used to safely exchange authorization codes and tokens, helping prevent tampering, leaks, or other related risks. The purpose of a client (and PKCE to confirm the client’s authenticity) is to ensure that the same user is proceeding through the authorization flow.
What is the actual purpose of Dynamic Client Registration?
The biggest misconception of Dynamic Client Registration is what it explicitly requires versus what it allows for. Because DCR doesn’t require a human’s presence, it could be misconstrued as a credentialing standard for an AI agent or LLM to claim, “Hey, I’m legitimate!”.
However, that isn’t the correct framing. DCR is not a super secure set of metadata parameters that magically allow for the AI agent to appear legitimate. Instead, DCR provides the mechanics for a client (e.g. AI agent) to authorize with a server (e.g. MCP server) programmatically. The rest is up to the server’s own policies. That said, DCR does allow for ample metadata fields, including entirely custom ones, that could be used for authorization logic. It also provides a mechanism for the authorization server to communicate to the client on what’s necessary. But DCR does not dictate how that authorization logic should work—that’s up to the authorization server’s design. In fact, the authorization server might still require a human to manually review a client; even in this scenario, DCR is still automating the registration mechanics and not the authorization logic.
Notably, DCR levels the varying security expectations of different MCP servers. For example, an MCP server that provides non-sensitive weather data might strictly use OAuth to maintain a client roster. Others might be more restrictive, with domain allowlists, manual review, or some other form of pre-registration.
Why is traditional pre-registration a poor fit for AI?
DCR isn’t technically necessary for AI agents. Humans could build an agentic system where MCP clients and MCP servers are manually pre-registered. For many products, this might be sufficient. However, for most at scale, it’s friction-heavy.
To understand why, let’s consider a hypothetical. Imagine that you had five MCP clients (various AI agents) and five MCP servers (various third-party or internal applications). For all five MCP clients to access all five MCP servers, there would need to be twenty-five pre-registration flows with a user present. As those numbers scale up, it quickly becomes impractical; nobody wants to spend their workday clicking through registration UI or hardcoding credentials.
Additionally, AI agents are non-deterministic. In some permissive workflows, they might be allowed to access arbitrary MCP services on a registry to conduct research, collect data, or execute actions. Dynamic Client Registration enables AI agents to register themselves by submitting metadata in lieu of a human’s manual approval.
Dynamic Client Registration’s flow, step-by-step
Dynamic Client Registration, excluding the OAuth 2.1 flow, is just a few steps.
The first step of Dynamic Client Registration is on the client’s side. The client (e.g. the MCP client) fetches metadata about the resource from the MCP server. The response will also include the authorization server’s URL.
With that, the client will ping the authorization server to register. In return, the authorization server will pass the client a set of registration details: a client ID, a client secret, and a registration access token (distinct from an access token, this token is so that the client can later update its registration).
Now, with a client ID and client secret, the client service can proceed with OAuth 2.1.
After, the rest is beyond the scope of DCR. OAuth 2.1’s authorization flow happens, an access token is minted, and the client and server could transact as normal.
What is Dynamic Client Registration Metadata?
Presently, DCR outlines 30 different metadata fields that might be used to facilitate a dynamic authorization grant. However, these are all optional. Rather, it’s up to the MCP server and MCP client’s designs on what metadata fields are applicable. The only field that’s semi-mandatory is redirect_uris that inform the authorization server where to send the user (along with an authorization code or access token) once the user has completed authentication and consent; however, that’s only applicable to redirect-based flows.
Beyond that, DCR just provides a toolkit of metadata to authenticate, but doesn’t mandate one method over another. Various MCP servers might require different flows. For instance, an MCP server that strictly requires authorization to rate limit requests doesn’t require the AI agent to be matched with a user account.
CIMD is an alternative to DCR
CIMD, or Client ID Metadata Document, is an alternative approach to DCR.
With DCR, the OAuth server must manage a database of client IDs and store client metadata. Additionally, the server is accountable for verifying the authenticity of clients. For applications that might have tens of thousands of clients, this poses a scaling and security challenge for servers. Servers need to store all of that information and could be vulnerable to a Denial of Service attack.
CIMD inverts the approach by entrusting clients to publicly host their metadata on a URL. For each request, the OAuth server will access the client’s metadata URL. While this does introduce latency, it does shift the burden back to each client instead of centralizing it on one server. Additionally, the server could easily check if the client’s metadata URI and the client’s redirect URI are from the same domain, hampering rogue actors attempting to impersonate legitimate clients.
Closing Thoughts
If you are interested in building scalable AI systems with MCP and DCR, consider booking a demo with Runlayer. Runlayer is a simple, safe orchestration system to connect with MCP servers via a shared registry. Runlayer provides out-of-the-box observability and security; additionally, it could be deployed on-prem for compliance-conscious organizations.
Discover enterprise-ready governance and the future of MCP today.
