MCP with Entra auth for Copilot and VS Code: preregistration is the part that matters

The most useful detail in this write-up is not the OAuth theory. It is the very specific fact that VS Code needs to be preregistered as an authorized client for your MCP app in Entra, using client ID aebc6443-996d-45c2-90f0-388ff96faa56, or the sign-in flow falls apart quickly.

That matters because a lot of MCP auth discussion still gets stuck on the wrong fix: people strip out the resource parameter to make Entra stop complaining. That might get a demo moving, but it is the wrong direction for enterprise use. The source does a good job showing why. MCP expects resource indicators, and Entra is validating them more strictly now with errors like AADSTS9010010 when the resource and scopes do not line up.

What this is really telling us

This is less a Copilot story and more an enterprise auth reality check for custom MCP servers. If your MCP server is meant to work with VS Code, Copilot-style clients, or internal agent tooling, preregistration is not optional plumbing. It is part of the product design.

The source also makes a fair correction on Dynamic Client Registration and client metadata documents. In consumer tooling, those can feel convenient. In enterprise environments, they expand the attack surface in ways many admins will not accept. That is the part a lot of developer-first MCP examples gloss over.

So the Entra position here looks reasonable to me. More annoying, yes. But also more honest about how enterprises actually control application trust.

The concrete setup worth copying

Two snippets from the source are the important ones.

First, the server exposes OAuth protected resource metadata and requires auth on the MCP endpoint:

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddMcp(options =>
    {
        options.ResourceMetadata = new ProtectedResourceMetadata
        {
            Resource = resourceUri,
            AuthorizationServers = { entraAuthority },
            ScopesSupported = { requiredScope },
        };
    });

app.MapGet("/health", () => Results.Ok(new { status = "healthy" }))
    .AllowAnonymous();

app.MapMcp("/mcp")
    .RequireAuthorization();

Second, the MCP app registration needs to line up with the resource and scope values the client will request:

{
  "Mcp": {
    "ServerUrl": "http://localhost:7071",
    "ResourceUri": "http://localhost:7071/mcp",
    "RequiredScope": "api://eba71e23-a335-4584-a90d-69d732c8a7ff/access_as_user"
  },
  "Entra": {
    "Authority": "https://login.microsoftonline.com/organizations/v2.0",
    "Audience": "eba71e23-a335-4584-a90d-69d732c8a7ff"
  }
}

The other practical detail I would not skip: set api.requestedAccessTokenVersion to 2 in the app manifest.

What I would watch

For most teams, the impact is narrow but important:

• If you built an MCP proof of concept with relaxed auth assumptions, verify it against Entra now.
• If your client stack silently drops or rewrites OAuth parameters, expect inconsistent behavior.
• If you want this to work in real tenant environments, design for app registration ownership, consent, and least privilege from day one.

That last point is where this gets strategic. Once MCP servers start backing Microsoft Copilot and AI agents, auth decisions become platform decisions. If your pattern depends on hacks against the SDK or against Entra validation, you are building on sand.

My take: this is a good, practical post because it pushes people away from the easy-but-wrong workaround. If you are wiring enterprise MCP into VS Code or internal automation, treat preregistration and scope alignment as first-class requirements. That is the boring answer, but in AI workflow automation, boring auth is usually the right auth.