MCP Dynamic Client Registration: Why it Matters and How To Accomplish it with Entra

Series: Enabling MCP at Enterprise Scale — Post 3 of 10

If you’ve tried to connect an MCP client protected by Microsoft Entra ID and hit an unexpected wall, this post is for you. It’s one of the most common friction points in enterprise MCP authentication — and it comes down to a single feature the MCP spec requires that Entra doesn’t support.

That feature is Dynamic Client Registration defined in OAuth RFC 7591. Here’s what it is, why it matters, and what you can do about it today.

What Is Dynamic Client Registration?

Dynamic Client Registration (DCR) is an OAuth standard — RFC 7591 — that lets OAuth clients register themselves with an authorization server programmatically, at runtime.

Without DCR, registering an OAuth client is a manual process. Someone goes into the IdP admin console, creates an app registration, configures the redirect URIs, copies the client ID and secret, and hands them to the developer. That works fine when you’re doing it once. It doesn’t work when MCP clients need to connect to new servers dynamically.

The MCP spec requires MCP Dynamic Client Registration for exactly this reason. Clients need to discover and connect to MCP servers without someone manually provisioning an OAuth app registration every time. DCR makes that possible — the client sends a registration request to the authorization server, gets back a client ID and credentials, and proceeds with the OAuth flow. No admin console, no manual steps.

Here’s what a minimal DCR request looks like:

POST /register HTTP/1.1 Host: auth.example.com Content-Type: application/json  {   "client_name": "My MCP Client",   "redirect_uris": ["https://client.example.com/callback"],   "grant_types": ["authorization_code"],   "response_types": ["code"] }

The authorization server responds with a client_id and (optionally) a client_secret. The client uses those credentials to proceed with the standard OAuth flow — no admin intervention required.

Why MCP Dynamic Client Registration Matters for Enterprise Deployments

In a small or personal deployment, you might register your OAuth app once and hardcode the credentials. Annoying, but manageable.

In an enterprise environment, that approach breaks down fast. Every new client-server combination needs its own app registration — a matrix of manual work that grows with every MCP server you add.

Here’s a concrete example. You have three MCP clients: Claude Desktop, a custom agent, and an IDE plugin. You have five MCP servers. Without DCR, that’s potentially fifteen separate OAuth app registrations to manage, keep in sync, and update whenever something changes. Add a sixth server and you’re back in the admin console three more times.

DCR collapses that. Clients register once, dynamically. The authorization server handles the rest.

The Entra Problem: No DCR Support

Microsoft Entra ID does not support Dynamic Client Registration.

This isn’t a bug or an oversight — it’s a product decision, and it’s been a known limitation for a while. Entra’s app registration model is built around manual configuration in the Azure portal or via the Microsoft Graph API. There’s no endpoint that accepts a DCR request per RFC 7591.

For MCP deployments in organizations running on Entra — which is a lot of enterprises — this creates a direct conflict with the MCP spec. The spec says clients should be able to register dynamically. Entra says they can’t. If you’re already connecting Microsoft Office 365 MCP servers in your environment, you’ve likely already run into this wall.

In practice, every MCP client that wants to connect to an Entra-protected resource needs a manually provisioned app registration. If you have five clients and ten MCP servers, someone is doing a lot of clicking in the Azure portal — and every time a new MCP server gets added, the cycle starts again.

Common Workarounds — and Their Limits

The obvious move is to create one shared app registration and distribute the client ID and secret to all your MCP clients. It works. But it means every client shares the same credentials, you can’t revoke access for one client without affecting all of them, and your audit logs can’t distinguish between clients. Security teams tend not to love this.

The other common approach is scripting app registrations via the Microsoft Graph API. Better than clicking through the portal — but you’re still managing a growing inventory of registrations, and the underlying problem hasn’t gone away.

Meet with an Obot Architect

Get expert guidance on deploying Obot as your enterprise MCP gateway and aligning it with your infrastructure.

👉 Click here to book a time that works with your schedule.

The Control Plane Fix for MCP Dynamic Client Registration

The cleaner solution is to put a DCR-capable control plane for MCP in front of MCP server to handle OAuth for Entra.

The control plane exposes a DCR endpoint to MCP clients. From the client’s perspective, MCP Dynamic Client Registration works exactly as the spec intends. Behind the scenes, the control plane holds the static Entra app registrations and handles the OAuth flow to Entra on behalf of the clients.

The result: clients register once, dynamically. The control plane manages the Entra configuration centrally. When a new MCP server gets added, you update the control plane — not every client.

Instead of this:

Client A → static config for Server 1 Client A → static config for Server 2 Client B → static config for Server 1 Client B → static config for Server 2 (repeat for every client/server combination)

You get this:

All clients → DCR endpoint on control plane Control plane → static config per server, managed once

The matrix of manual registrations collapses into a single configuration layer. New clients register dynamically. New servers get added to the control plane once. Entra never needs to know about DCR.

What to Watch For When Implementing This Pattern

A few things worth knowing as you build this out:

Redirect URI management still matters. Even with a control plane handling Entra, the control plane’s redirect URIs must be registered correctly in your Entra app registrations. This is usually a one-time setup, but it’s the first place to check when the OAuth flow breaks.

Token lifetimes are set in Entra. The control plane can handle token refresh, but the initial token lifetime and refresh token policies are configured in Entra. Short-lived access tokens (15–60 minutes) with longer-lived refresh tokens is the typical starting point. Set these before you go to production.

The control plane holds sensitive credentials. It holds the Entra app credentials and issues tokens on behalf of clients — treat it accordingly. Restrict access, rotate credentials on a schedule, and ensure the control plane itself is behind your standard access control for MCP servers.

This isn’t Entra-specific. Any IdP that doesn’t support DCR has the same problem. Entra is just the most common one we see in enterprise deployments. The control plane pattern applies equally to others.

Bottom Line

If your organization runs on Entra, DCR support isn’t coming from Microsoft anytime soon. The practical path forward is a control plane that bridges the gap — giving MCP clients a standards-compliant MCP Dynamic Client Registration endpoint while handling the Entra-specific configuration internally.

For a broader look at what secure MCP access requires across your organization, that’s a good next read.

It’s one of those problems that looks like a blocker until you understand the architecture. Then it’s just a configuration decision.

Next in the series: Token Brokering for MCP: Why Your Clients Shouldn’t Hold Raw OAuth Tokens

Get Started with Obot

Try Obot on GitHub · Schedule a demo · Read the docs