Custom connector cannot authenticate to first-party Microsoft Entra MCP servers (Business Central, Power BI/Fabric, M365) — OAuth succeeds but Claude never exchanges the code at /token

[nalamo1234]

What happened?

When adding a first-party Microsoft MCP server (Microsoft Business Central at https://mcp.businesscentral.dynamics.com) as a custom connector in claude.ai, authentication fails even though Microsoft Entra ID reports the sign-in as successful.

The OAuth callback completes and Entra sign-in logs show Status: Success for both the app registration and the Business Central resource. However, the connector then fails with "Authorization with the MCP server failed" (reference ofid_128cd77473218bac). Per detailed HTTP traces in related issue #506, Claude's backend performs OAuth discovery (GET on the .well-known metadata endpoints, both return 200) but never POSTs to the /token endpoint — the authorization code is never exchanged for a token. Because Claude never obtains a token, no authenticated MCP request is ever made.

The same Business Central server, same Entra tenant, same credentials, and same user account connect successfully through three other clients:

• The mcp-remote bridge in Claude Desktop (which sends an explicit RFC 8707 resource indicator and returns live BC data)
• Claude Code (connects, authenticates, loads tools, runs queries — see Claude.ai web custom connector cannot configure required Microsoft Business Central MCP headers #427)
• ChatGPT Developer Mode (completes the code exchange and invokes tools — see claude.ai custom MCP connector with Entra ID: OAuth callback succeeds, but Claude never exchanges authorization code at /token #506)

This confirms the Business Central server validates correctly-acquired tokens fine. The failure is specific to the claude.ai custom connector's token-acquisition step with Microsoft Entra ID as the authorization server.

Critically, none of the documented customer-side fixes can resolve this for a first-party Microsoft server:

1. Entra ID does not support Dynamic Client Registration (DCR).
2. The documented Application ID URI fix (for AADSTS9010010) cannot be applied — Entra requires the Application ID URI to use a verified domain the organization owns, and the customer does not own businesscentral.dynamics.com (Microsoft does). Setting it returns: "Values of IdentifierUris property must use a verified domain of the organization or its subdomain."
3. oauth_anthropic_creds / custom_connection are documented as "Contact Anthropic" (request submitted to mcp-review@anthropic.com, awaiting response).

Secondary blocker (see #427): even if auth is resolved, BC requires custom headers (TenantId, EnvironmentName, Company, ConfigurationName) that the web connector UI provides no field for.

This affects an entire category of first-party Microsoft servers (Business Central, Power BI/Fabric, Microsoft 365) and any organization using Microsoft Entra ID. Consolidates and continues #397 (closed as not-planned before diagnosis was complete). Related: #427, #290, #496, #503, #506, #520.

What did you expect to happen?

After a successful Microsoft Entra sign-in, Claude should exchange the authorization code at the /token endpoint, obtain an access token, and establish an authenticated MCP session — as it does in Claude Code and as ChatGPT Developer Mode does. The connector should then be usable across claude.ai web, mobile, and Desktop.

Steps to reproduce

1. In claude.ai, go to Settings > Connectors > Add custom connector.
2. Enter URL: https://mcp.businesscentral.dynamics.com
3. Under Advanced settings, enter the OAuth Client ID of a Microsoft Entra app registration (multi-tenant, public client, redirect URIs https://claude.ai/api/mcp/auth_callback and https://claude.com/api/mcp/auth_callback, delegated Business Central permissions with admin consent).
4. Click Connect and complete the Microsoft sign-in.
5. Observe: Microsoft sign-in succeeds (Entra logs show Status: Success), but Claude returns "Authorization with the MCP server failed" with an ofid_ reference.

Area

MCP Connector (adding/managing servers)

MCP Server (if applicable)

https://mcp.businesscentral.dynamics.com

Error messages or logs

- Most recent failure reference: ofid_128cd77473218bac
- Consolidates: #397 (closed not-planned)
- Related open issues: #427, #290, #496, #503, #506, #520
- Willing to provide: full mcp-remote bridge logs, decoded token aud claims from a working session, Entra sign-in log exports
- Anthropic connector auth docs referenced for DCR/CIMD/oauth_anthropic_creds/Application ID URI options

Additional context

Actual Behavior
OAuth callback completes and Entra reports success, but Claude's backend never POSTs to /token, never obtains a token, and the connector fails with "Authorization with the MCP server failed" (ofid_128cd77473218bac). The connector remains disconnected. No token ever reaches the Business Central server.

[nalamo1234]

A few additional findings that reinforce this is an Anthropic-backend / connector-flow issue, and that it's solvable:

1. Independent backend-side confirmation (M365). claude-plugins-official#1494 documents the M365 connector failing with the same pattern, and notes Entra sign-in logs show NO failed auth attempt at the time the error displays — meaning the request is rejected by Anthropic's backend before it reaches the tenant, not by any tenant access policy. That issue also cites a Microsoft Q&A thread where Microsoft's own guidance points to Anthropic's backend as the cause. Same root cause, different Microsoft first-party connector — this spans the whole Microsoft Entra connector family.

2. The problem is fully solvable. Michael Sourbron published a working OAuth 2.1 adapter specifically for Business Central (Medium, April 2026): it speaks OAuth 2.1 + DCR + PKCE to Claude on one side and OAuth 2.0 to Entra on the other, forwarding an unmodified Entra bearer token to BC, and handles BC's required headers via BC_ENVIRONMENT / BC_MCP_CONFIG. The token-broker pattern is also confirmed working by multiple people in claude.ai custom MCP connector with Entra ID: OAuth callback succeeds, but Claude never exchanges authorization code at /token #506. The open question is why a customer must self-host a proxy for a first-party Microsoft server rather than Claude supporting the flow natively (e.g. via oauth_anthropic_creds).

3. Microsoft officially expects this to work. Microsoft Learn now publishes "Connect Business Central MCP Server to non-Microsoft hosts," which explicitly lists Claude as a supported host and documents the Entra app-registration workaround. So Microsoft's product expectation is that Claude connects to BC — the gap is on the connector-flow side.

Request: could Anthropic confirm the intended supported path for first-party Microsoft Entra-backed servers, and whether oauth_anthropic_creds is the route? Happy to test any candidate fix.

[nalamo1234]

Retested August 3, 2026, after the MCP 2026-07-28 spec release (which included "stronger OAuth and OIDC authorization"). The custom connector to Business Central still fails identically — new reference ofid_bed244ae91d8374d. Entra sign-in still succeeds; Claude's backend still does not complete the /token exchange. The 2026-07-28 OAuth changes do not appear to have addressed the custom-connector Entra path (BC / first-party Microsoft servers). Same signature as originally reported.

[VadimIM]

We're seeing same as well. Unable to connect. Seeing success in Entra portal, but error in Claude.ai web, and Claude Desktop

Authorization with Microsoft Dataverse failed. You can check your credentials and permissions. Entra Trace ID: 0e67cca1-753d-4a09-bed0-e14993e38300. If this persists, share this reference with support: “ofid_857fd44f94a2e3c8”

[nalamo1234]

Consolidating related reports + narrowing the failure mode

This issue has at least eight open or recently-closed siblings that appear to share a root cause. Linking them here so they can be triaged as one:

Never POSTs to /token after a successful callback (claude.ai web):

• Custom MCP Connector Auth Failure - Business Central MCP Server (ofid_790e848129dc7fb8) #397 — Business Central MCP server (same server as this issue)
• Power BI MCP Server — Authorization with the MCP server failed after OAuth completes (Entra ID) #496 — Power BI / Fabric MCP (api.fabric.microsoft.com/v1/mcp/powerbi)
• claude.ai custom MCP connector with Entra ID: OAuth callback succeeds, but Claude never exchanges authorization code at /token #506 — Entra ID; reporter confirms the identical server, Entra app, and credentials work in ChatGPT Developer Mode
• Custom connector fails at token exchange — server issues auth code correctly, claude.ai never calls /token (ofid_f35608ed2b59d7ad) #215, MCP Server Token Exchange Fails During OAuth Flow #360 — same symptom with non-Microsoft identity providers (GitHub upstream, Cloudflare Workers OAuth provider), both closed as not planned

Token obtained, but the follow-up request omits Authorization: Bearer (Claude Desktop):

• Custom MCP connector: token issued successfully server-side, but Claude Desktop never uses it — "Authorization with the MCP server failed" / McpAuthorizationError #690 — non-Microsoft server; token issued successfully server-side, then zero authenticated requests reach the server

These may be one bug or two adjacent ones, but the shared signature is consistent across every report: the upstream authorization server logs a clean success, and the failure occurs entirely on Anthropic's side after the callback. Entra is not the variable — #215, #360, and #690 reproduce it against GitHub, Cloudflare, and custom OAuth servers. Multiple reporters independently confirm the same server works in Claude Code and in ChatGPT Developer Mode, which isolates the defect to the claude.ai / Claude Desktop connector path.

Separate but compounding — headers: even with token exchange fixed, Business Central needs TenantId, EnvironmentName, Company, and ConfigurationName sent as HTTP headers in addition to the Entra bearer token. The connector UI's "Request headers" option appears to be an alternative auth mode rather than an additive one, and per #644 it is currently ignored (the client falls back to OAuth and uses the header name as client_id). See also #10 (open since January) and #427 (closed as not planned).

Three questions that would unblock server-side debugging:

1. Is the /token POST gated on a condition these servers don't meet — a client_secret, a DCR registration response, or a specific field in the Protected Resource Metadata? Entra supports neither DCR nor a client secret for public-client PKCE flows, and the MCP spec's auth section treats those as optional.
2. For Custom MCP connector: token issued successfully server-side, but Claude Desktop never uses it — "Authorization with the MCP server failed" / McpAuthorizationError #690's variant: is there a known path where a token is successfully obtained but not attached to the subsequent MCP request?
3. Is there any plan to support custom headers alongside OAuth rather than instead of it? That single change would unblock every first-party Microsoft MCP server at once — Business Central, Fabric/Power BI, and the M365 endpoints in "Authorization with the MCP server failed" despite admin consent granted #290 and M365 Connector "Authorization with the MCP server failed" for single non-admin user — Entra logs show clean success #520.

Happy to supply HAR captures, Entra sign-in log entries, and correlation IDs for any of the above.

[Strong-Dollar]

We too encountered this issue and did not find a viable workaround. As such we're waiting on a resolution from Anthropic.

[nalamo1234]

Update — request headers alongside OAuth are now documented; token-exchange defect is the remaining blocker.

Since filing this, Anthropic's connector docs have added an "Authenticating with request headers" section (claude.com/docs/connectors/custom/remote-mcp) that explicitly supports custom headers in addition to OAuth — headers are sent on every request alongside the OAuth bearer token, and the docs name routing headers as a supported use case. That directly addresses the header half of this report (and #427): Business Central's four routing headers (TenantId, EnvironmentName, Company, ConfigurationName) are exactly this shape.

Two caveats on that half: it's a gated beta ("contact Anthropic for early access"), and header names are restricted to a reviewed allowlist — the four BC names would need to be added. I'm pursuing both through support/our account contact.

That leaves a single blocker for the Entra first-party servers: Claude's backend still never POSTs to Entra's /token endpoint after a successful OAuth callback. The header capability does nothing to fix this — even with headers configured, authorization fails because no access token is ever obtained. This is the same behavior reported in #506, #690, #397, #496, and modelcontextprotocol/modelcontextprotocol#2157, so it appears to be one backend defect affecting Business Central, Power BI/Fabric, and M365 alike.

Could someone confirm whether the missing /token exchange is on the roadmap? With headers now handled, that's the only thing standing between these first-party Microsoft servers and working custom connectors.

[joaquin-orono]

Any workaround for this issue?

[LC1973]

Also hitting this with a fully self-hosted custom MCP server (not one of Microsoft's first-party ones — a personal Go MCP server behind Caddy, using our own Entra app registration for auth), so it's not limited to Business Central/Power BI/M365.

Same signature: Entra sign-in reports success, Claude reports "Authorization with the MCP server failed."

Entra Trace ID: e4824106-5ca5-4e90-992a-5f349dc52d00
ofid_17b6dbf723483e28

One data point that might help triage: we tried moving the redirect URI between Entra's web, publicClient (Mobile/desktop), and spa platform buckets on the app registration. publicClient and spa both reproduced this failure; reverting to web restored a working connection. So whatever's gating the /token call, it seems to depend on which platform the redirect URI is registered under, at least for our tenant.