claude.ai custom MCP connector with Entra ID: OAuth callback succeeds, but Claude never exchanges authorization code at /token

[jvitti93]

MCP server URL

https://example.mcp.com

Where does the issue occur?

When auth finishes and redirects back to Claude.ai

Transport used

streamable-http

Client registration type

Static

SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

When did you last reproduce this?

2026-06-29 15:27 EST

Browser and OS

Edge 149.0.4022.52 on macOS 26.5.1

Describe the issue

A custom remote MCP connector protected by Microsoft Entra ID fails to connect on claude.ai web despite a spec-compliant MCP server and a verified OAuth configuration.

After the user successfully signs into Microsoft, Claude discovers the OAuth metadata (/.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server) but never completes the OAuth authorization code exchange by POSTing to Entra's /token endpoint. The connector then displays:

Authorization with the MCP server failed. You can check your credentials and permissions.

As a control, the identical MCP server, Entra application, OAuth client credentials, and user account work successfully in ChatGPT Developer Mode. ChatGPT completes the authorization code exchange, presents a bearer token to the MCP server, completes MCP initialization, and successfully invokes tools.

The evidence suggests the failure occurs between the OAuth callback and the authorization code exchange.

The production endpoint URL has been redacted because it is customer owned & publicly recognizable. I can provide the actual URL privately to an Anthropic engineer if needed.

Issue details

Environment

Claude Pro (web)
MCP server: Bun + @modelcontextprotocol/sdk@1.29.0
Transport: Streamable HTTP
Hosting: CloudFront → Nginx → Bun (EC2)
TLS: ACM certificate
Authorization Server: Microsoft Entra ID (single tenant)
OAuth client: Confidential client using static client_id and client_secret
PKCE: S256
OAuth discovery:
/.well-known/oauth-protected-resource
/.well-known/oauth-authorization-server

Server behavior

The MCP server:

returns RFC 9728 protected-resource metadata
returns RFC 8414 authorization-server metadata
correctly responds with
401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="..."

for unauthenticated requests

validates Entra access tokens against Microsoft's JWKS
supports MCP sessions via Mcp-Session-Id

Observed request sequence from Claude

POST /                                       -> 401
GET /.well-known/oauth-protected-resource    -> 200
GET /.well-known/oauth-authorization-server  -> 200

No authenticated MCP requests follow.

Microsoft Entra interactive sign-in logs show the user authentication succeeds.

Microsoft Entra non-interactive sign-in logs show no authorization code exchange reaching the /token endpoint for these attempts.

Expected behavior

After the user successfully authenticates with Microsoft Entra ID, Claude should:

Exchange the authorization code at the authorization server's /token endpoint.
Receive an access token.
Send authenticated requests to the MCP server using the bearer token.
Complete MCP initialization.
Allow MCP tools to execute normally.

This is the behavior observed when the identical server is used with ChatGPT Developer Mode.

Logs from your server

Claude backend (python-httpx/0.28.1)

POST /                                       -> 401
GET /.well-known/oauth-protected-resource    -> 200
GET /.well-known/oauth-authorization-server  -> 200

(no authenticated requests received)

Control experiment using ChatGPT Developer Mode:

POST / NO_AUTH
GET /.well-known/oauth-protected-resource

POST / Authorization: Bearer ...
  -> token validated

POST / Authorization: Bearer ...
  -> token validated

GET / Authorization: Bearer ...
  -> token validated

POST / Authorization: Bearer ...
  -> token validated

The MCP server successfully validates the bearer token and completes initialization when used with ChatGPT.

Additional context

Troubleshooting already performed:

Same MCP server succeeds in ChatGPT Developer Mode.
Same Entra tenant.
Same Entra application.
Same OAuth client credentials.
Same user account.
Redirect URI verified.
Scope/resource verified.
PKCE verified.
Token validation verified.
Conditional Access ruled out.
Admin consent verified.
Multiple delete/recreate cycles of the Claude connector.
Tested on both a production domain and a temporary Cloudflare Tunnel with identical results.

Reference connector IDs:

ofid_5e20d750d1b12aed
ofid_512b144951a6a391
ofid_4c768afec4202a80
ofid_95f8b17b5942503a
ofid_7eccf73ab692f8dc
ofid_477cd15b1a5372ef
ofid_c9dbbf7257571eea
ofid_fef67c35cb18c4de

Similar reports

This may be related to, but appears distinct from:

• Cowork custom connector (Supabase OAuth + Vercel): OAuth succeeds but post-auth MCP request omits Authorization header → 401 (ofid_8f999a7d09ef27b3) #482 – OAuth succeeds but authenticated MCP requests omit the Authorization header.
• Custom Connector OAuth Connection Failure - Laravel Passport MCP Server (ofid_0fbe1ab3541c2da4) #449 – Laravel Passport OAuth connection failures.
• Custom connector OAuth 2.1/PKCE — Connect button never appears on Team plan (DCR + discovery endpoints fully implemented) #448 – DCR/discovery issue preventing the Connect button from appearing.

In this case, OAuth discovery succeeds and the Connect flow is presented. The apparent failure occurs after successful user authentication, where the authorization code does not appear to be exchanged for an access token before MCP initialization.

I'm happy to provide additional diagnostics (sanitized server logs, Entra sign-in log JSON, HTTP traces, or a reproducible test environment) if they would help with investigation.

[nalamo1234]

Same signature here with Microsoft's official Business Central MCP server (Entra ID auth) — tracked in #397.

Setup: Claude web custom connector, Microsoft Entra ID, multi-tenant app, static client_id, PKCE S256. OAuth callback completes, Entra sign-in logs show Status: Success, discovery succeeds — but Claude's backend sends no authenticated MCP request afterward, and the connection fails with an ofid_ auth error / 401.

Same "works elsewhere, fails in Claude.ai" pattern you noted with ChatGPT Developer Mode: the identical BC server works for me through the mcp-remote bridge in Claude Desktop. The bridge succeeds because it uses a static pre-registered client plus an explicit RFC 8707 resource indicator (resource=https://mcp.businesscentral.dynamics.com/). BC accepts that token and returns live data. So BC validates correctly-acquired tokens fine — the differentiator appears to be that the connector isn't acquiring/sending a token with the resource indicator (and therefore the correct aud claim).

Also relevant: Entra ID doesn't support DCR, and per Anthropic's connector auth docs the out-of-the-box flows are DCR and CIMD, with oauth_anthropic_creds / custom_connection being "Contact Anthropic." That may be the underlying reason the custom-connector-by-URL path doesn't complete for Entra-backed servers.

[drgibbs11]

Adding another enterprise data point here.
Environment: Claude Enterprise custom MCP server deployed on Azure Container Apps (Central US), Microsoft Entra ID single-tenant, streamable-http transport, static client credentials (pre-registered, not DCR).
What we built: Full RFC 9728 PRM + RFC 8414 AS metadata on our domain (workaround for #82), DCR endpoint returning pre-registered client_id with token_endpoint_auth_method: none, PKCE S256, isFallbackPublicClient: true on the Entra app registration. Token validation in-app via jwt-validate against Entra JWKS.
What happens: Microsoft login screen briefly appears, then immediately returns to Claude with the failure message. No sign-in event appears in Entra ID sign-in logs, consistent with the authorization code never being exchanged at /token.
Reference IDs:

ofid_6f15f83431fe79ac (most recent attempt, 2026-07-01)
ofid_9e6a6e4cb0bf51b8 (earlier attempt)

@crondinini-ant — could you look up these ofids against broker-side logs to confirm where the flow is failing?

[abrez-endsight]

an independent reproduction with a fully isolated variable set: same warehouse-backed MCP server, same Entra app registration, works via ChatGPT, fails via Claude specifically at Easy Auth's callback, transport ruled out.

[brinawebb]

Independent confirmation of this from a different environment -- same symptom exactly. Custom connector ("Individual sign-in" + static Client ID, not confidential-client), Microsoft Entra ID single-tenant authorization server, our own MCP server backend (Azure Functions).

• Entra sign-in log shows a Status: Success entry for our Client -> Resource app pair, confirming authentication completes.
• • Our backend's Application Insights shows zero incoming requests across five separate attempts (different browsers, with/without a client secret, and a fresh InPrivate session) -- confirming, like the OP, that Claude never gets far enough to call our API.
• • • Same failure point: "when auth finishes and redirects back to Claude.ai."
      This matches the OP's diagnosis of the failure occurring between the OAuth callback and the authorization code exchange, not anywhere in our Entra config or backend.

Reference IDs from our attempts: ofid_da61a28bbac08e28, ofid_5095b2bc8101ba0f, ofid_49862dba8cbe0045, ofid_b4920ca628bdcf8f, ofid_76e325a2a26f5897, ofid_a8043aa802ed72e5

[jvitti93]

Workaround: front Entra with your own OAuth 2.1 AS (token-broker pattern).

Instead of exposing Entra directly as the Authorization Server, put a minimal OAuth 2.1 AS of your own in front and
federate to Entra privately. Claude only talks to your AS; Entra becomes an upstream IdP Claude never sees. This
dodges the bug because you control the AS Claude hits: it advertises the metadata Claude expects and accepts a static
pre-registered client (no DCR) — so /token actually gets called and completes. Your AS then does its own OAuth leg to
Entra as a normal confidential client, gets the real Entra token, and attaches it when forwarding to the backend MCP.

One gotcha: Claude calls /authorize and /token at the resource host root regardless of what the metadata advertises,
so route both there and use the RFC 8707 resource param (+ auth_code lookup on /token) to identify the target — the
same resource-indicator mechanism the working clients in this thread rely on. Net: Claude runs its supported flow
against a compliant AS, and Entra's lack of DCR stops mattering because it's no longer the AS Claude sees.

[brinawebb]

Workaround: front Entra with your own OAuth 2.1 AS (token-broker pattern).

Instead of exposing Entra directly as the Authorization Server, put a minimal OAuth 2.1 AS of your own in front and federate to Entra privately. Claude only talks to your AS; Entra becomes an upstream IdP Claude never sees. This dodges the bug because you control the AS Claude hits: it advertises the metadata Claude expects and accepts a static pre-registered client (no DCR) — so /token actually gets called and completes. Your AS then does its own OAuth leg to Entra as a normal confidential client, gets the real Entra token, and attaches it when forwarding to the backend MCP.

One gotcha: Claude calls /authorize and /token at the resource host root regardless of what the metadata advertises, so route both there and use the RFC 8707 resource param (+ auth_code lookup on /token) to identify the target — the same resource-indicator mechanism the working clients in this thread rely on. Net: Claude runs its supported flow against a compliant AS, and Entra's lack of DCR stops mattering because it's no longer the AS Claude sees.

This worked, thank you!