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 2.0 standard from RFC 7591 that lets OAuth clients register themselves with an authorization server programmatically, at runtime. In MCP it’s part of the MCP authorization specification, with the MCP authorization spec also supporting this as a backward-compatible capability.
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. The model context protocol handles authorization at the transport layer, and the MCP client acts on behalf of the resource owner when connecting to restricted servers. 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, and dynamic registration in the MCP authorization specification returns a client ID and credentials so it can proceed 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 through the authorization code flow, where the returned authorization code is exchanged securely after user consent. No admin intervention is 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. Authentication happens when the MCP client first connects to a remote MCP server, which is exactly where the Entra limitation appears. 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. Without a standardized authorization flow across MCP servers, implementations become inconsistent, operationally fragile, and prone to dangerous MCP OAuth shortcuts. 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.
The Control Plane Fix for MCP Server Dynamic Client Registration
The cleaner solution is to put a DCR-capable control plane for MCP in front of MCP servers 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, and the MCP client reads a metadata document to discover the corresponding authorization server instead of relying on manual configuration. Behind the scenes, the control plane holds the static Entra app registrations and handles the OAuth flow to Entra on behalf of the clients.
In a full MCP OAuth setup, that usually means exposing /authorize and /token, optionally /register, plus the login and consent experience for the user’s browser.
The result: clients register once, dynamically. The control plane manages the Entra configuration centrally. When you want to add a new MCP server, 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. Behind the scenes, the control plane acts as a central MCP security proxy and publishes protected resource metadata at a resource metadata URL; clients use it for authorization server discovery, locate the right OAuth authorization server, then fetch and validate that server’s authorization server metadata to confirm its authorization server endpoints.
A control plane also lets MCP servers implement the OAuth 2.0 Protected Resource Metadata specification, so a corresponding authorization server can be located efficiently. That improves onboarding, too, and is a natural place to enforce critical MCP security best practices. Users get a standardized single-click web consent interface instead of bespoke per-server setup.
This is exactly the pattern Obot implements out of the box. Connect your Entra app registration once — Obot handles DCR for every client from there. Try Obot for free or talk to an architect if you’re unsure where to start.
Common Pitfalls to Watch For When Implementing This Pattern
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. The authorization request sends the user’s browser to the authorization URL and then back during the authorization code flow, where both the redirect URI and state must be validated. 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) paired with longer-lived refresh tokens are the typical starting point; the access token itself is issued at the token endpoint during the authorization code exchange. Proof Key for Code Exchange (PKCE) is mandatory under OAuth 2.1, so public clients should use it instead of a client secret. 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. Secure authorization depends on token validation at the resource server, and skipping it can allow unauthorized access to protected resources. Every token issuance and tool call should also be logged and audited for forensics. 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, and it’s one of several strategic MCP security risks leaders must address. Entra is just the most common one we see in enterprise deployments. The control plane pattern applies equally to others. When implementing OAuth, make sure consent clearly shows the requested scopes at the authorization endpoint, and that clients ask only for what they need under least privilege.
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 by implementing the MCP OAuth authorization flow and, where needed, running the authorization server as a separate entity from the resource server. The MCP server acts as the resource server, while the MCP client discovers and follows the authorization mechanism the control plane exposes.
Secure MCP access is a good next read for a more extensive look at what it requires across your organization.
It’s one of those problems that looks like a blocker until you understand the architecture. Then it’s just a configuration decision. While more involved, this approach is preferable to API keys, because clients can request access to and access protected resources with revocable tokens instead of static secrets. The Obot AI Learning Center for MCP and agentic AI covers gateways, catalogs, and authentication patterns across MCP in more depth.
