Custom MCP server OAuth flow fails with "code: Field required" and "ofid" errors when using Microsoft Azure AD as upstream identity provider

[aferguson024]

MCP server URL

Self-hosted Softeria ms-365-mcp-server (https://github.com/Softeria/ms-365-mcp-server) running on DigitalOcean, behind Cloudflare Tunnel + Cloudflare Access

Where does the issue occur?

When auth finishes and redirects back to Claude.ai

Transport used

streamable-http

Client registration type

Dynamic Client Registration (DCR)

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-03-28 17:00 GMT

Browser and OS

No response

Describe the issue

When connecting a custom remote MCP server to claude.ai that uses Microsoft Azure AD (Entra ID) as its upstream OAuth identity provider, the OAuth flow consistently fails after the user successfully authenticates with Microsoft. The failure occurs inside claude.ai's backend — the MCP server's /token endpoint is never called, confirmed via server-side logs.Two distinct error patterns are observed depending on the connection attempt:Pattern 1 — code: Field required
Returned as a JSON error in Anthropic's own validation format during the callback stage:
json{"type":"error","error":{"type":"invalid_request_error","message":"code: Field required"},"request_id":"req_011CZVnQcRWQ5GC8Rp167Ev9"}Pattern 2 — ofid authorization failure
Shown in the claude.ai UI after the Microsoft consent screen is accepted:
Authorization with the MCP server failed. You can check your credentials and permissions.In both cases, Microsoft successfully authenticates the user and redirects to https://claude.ai/api/mcp/auth_callback?code=XXX&state=YYY. Claude.ai's backend then fails to process the callback before ever contacting the MCP server's /token endpoint.

Issue details

Product: claude.ai web
Plan: Team
Date: 2026-03-28
Transport: Streamable HTTP
Auth: OAuth 2.1 with Dynamic Client Registration (DCR)
Upstream IdP: Microsoft Azure AD (Entra ID) — tenant-specific

MCP server: Self-hosted Softeria ms-365-mcp-server
URL: https://ms365-mcp.westend-dental.com
Infrastructure: DigitalOcean droplet behind Cloudflare Tunnel + Cloudflare Access

Error reference IDs:
  req_011CZVnQcRWQ5GC8Rp167Ev9
  req_011CZVnuHrrkzaP6z146EwoT
  req_011CZVo8UPEZe3GJeTHZqFkS
  ofid_8b4ebc5243fe881f
  ofid_ef182e8bd15b391b
  ofid_18e6f53c612c30aa
  ofid_cb4c569412fa3f49
  ofid_0aad3ac70e7713d3

OAuth metadata endpoint: https://ms365-mcp.westend-dental.com/.well-known/oauth-authorization-server
Redirect URIs registered in Entra:
  https://claude.ai/api/mcp/auth_callback
  https://claude.com/api/mcp/auth_callback
Azure AD app: public client flows enabled, grant types: authorization_code + refresh_token, PKCE: S256

Cloudflare Access bypass policies confirmed working for:
  /.well-known/oauth-authorization-server
  /register
  /authorize
  /token

Expected behavior

After the user authenticates with Microsoft and accepts the consent screen, Microsoft should redirect to https://claude.ai/api/mcp/auth_callback?code=XXX&state=YYY. Claude.ai's backend should then send the authorization code to the MCP server's /token endpoint, which exchanges it with Microsoft for an access token and returns it to claude.ai. The connector should show as Connected and MCP tools should become available.

Logs from your server

No server-side logs are generated during the failure — the MCP server's /token endpoint is never called by claude.ai. This was verified by checking journalctl -u ms365-mcp immediately after each failed connection attempt. All OAuth endpoints (/register, /authorize, /token) were independently verified to function correctly outside of claude.ai using curl and the MCP Inspector.

Additional context

The OAuth flow architecture is a proxy pattern: the MCP server's /authorize endpoint proxies to Microsoft's OAuth endpoint, and the /token endpoint exchanges the code with Microsoft Graph on the user's behalf. This is a common pattern for MCP servers acting as Microsoft Graph intermediaries.
The following were all attempted and confirmed not to resolve the issue:

Providing a pre-registered OAuth Client ID and Secret in claude.ai's Advanced connector settings (bypasses DCR)
Adding a claudeai custom scope to the Azure AD app registration's "Expose an API" section
Both https://claude.ai/api/mcp/auth_callback and https://claude.com/api/mcp/auth_callback registered as redirect URIs
Enabling --enable-dynamic-registration flag on the MCP server

The issue appears specific to Microsoft Azure AD as the upstream IdP. The code: Field required error message is Anthropic's own Pydantic/validation format, strongly suggesting the failure is in claude.ai's callback handler rather than in the MCP server or Microsoft's OAuth implementation.

[aferguson024]

Further Context

To rule out infrastructure interference, Cloudflare Access was completely removed from the endpoint, leaving only the Cloudflare Tunnel (no authentication layer between claude.ai and the MCP server). The identical ofid error persisted, confirming the failure is entirely within claude.ai's OAuth callback processing and unrelated to any proxy or firewall in front of the MCP server.

[aferguson024]

Update — Cloudflare Access confirmed not the cause

To fully rule out infrastructure interference, Cloudflare Access was removed entirely from in front of the MCP server endpoint, leaving only a Cloudflare Tunnel with no authentication layer. The identical ofid error persisted across both a DigitalOcean Linux server and a Mac mini running macOS. This definitively confirms the failure is inside claude.ai's OAuth callback handler and is unrelated to any proxy, firewall, or server OS in front of the MCP server.

[hamishll]

This might be the solution you're looking for.

Looks like Anthropic recently tightened how their MCP client parses the WWW-Authenticate header on 401s from /mcp — relative resource_metadata paths are now silently rejected, so OAuth discovery never starts and the client just loops on unauthenticated requests. To fix it, make sure resource_metadata is an absolute URL (e.g. https://your-host/.well-known/oauth-protected-resource).

 const proto = req.headers.get("x-forwarded-proto") ?? "https";
  const host  = req.headers.get("x-forwarded-host") ?? req.headers.get("host");
  const resourceMetadata = `${proto}://${host}/.well-known/oauth-protected-resource`;

  return new Response(JSON.stringify({ error: "Unauthorized" }), {
    status: 401,
    headers: {
      "WWW-Authenticate":
        `Bearer realm="MCP", resource_metadata="${resourceMetadata}"`,
    },
  });

[bjimmyd]

Hitting this exact issue connecting Claude desktop to a custom remote MCP server backed by Microsoft Entra ID. Wanted to add data points that may help narrow it down — my setup is not the relative-resource_metadata misconfiguration suggested above, so the bug appears to bite spec-compliant servers too.

Setup

• MCP server on Azure Container Apps, behind HTTPS at a canonical FQDN.
• Auth: OAuth 2.1 with Microsoft Entra ID as the upstream authorization server (per MCP spec §2.3 — RFC 9728 Protected Resource Metadata pointing at Entra's v2 OIDC endpoint).
• Connector configured via Claude desktop → Add custom connector → Advanced settings, with manual OAuth Client ID + Client Secret (no DCR).
• Both https://claude.ai/api/mcp/auth_callback and https://claude.com/api/mcp/auth_callback registered as redirect URIs on the Entra app.
• Canonical https URI added to the Entra app's identifierUris so resource=<canonical-uri> per RFC 8707 is accepted by Entra.

What works

• az account get-access-token --resource api://<app-id> produces a v2 token; server validates it; tools/list returns the full tool list. End-to-end token validation is fine.
• Both well-known documents are correct and absolute:

GET /.well-known/oauth-protected-resource
{
  "resource": "https://<fqdn>",
  "authorization_servers": ["https://login.microsoftonline.com/<tenant>/v2.0"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["https://<fqdn>/mcp.access"]
}

• 401 on /mcp returns an absolute resource_metadata URL in WWW-Authenticate:

WWW-Authenticate: Bearer realm="MCP", resource_metadata="https://<fqdn>/.well-known/oauth-protected-resource"

What fails

• Click Connect in Claude desktop → Microsoft login screen renders → login succeeds → browser shows "Couldn't connect / Taking you back to the desktop app" → desktop app shows "Authorization with the MCP server failed."

What Entra logs reveal

Inspecting auditLogs/signIns for the app registration via Graph:

• Interactive sign-ins around the connect attempts succeed (errorCode: 0).
• No nonInteractiveUser token-exchange events follow. Claude never hits Entra's /oauth2/v2.0/token endpoint with the authorization code.
• The interactive entries show authenticationProtocol: "none", clientCredentialType: "none", incomingTokenType: "none" — i.e. Entra is just satisfying SSO claims from a prior session, not handling a fresh response_type=code request.

In other words: Microsoft successfully redirects Claude back to claude.com/api/mcp/auth_callback?code=…&state=…, and Claude's callback handler bails before exchanging the code. Matches earlier descriptions of the failure happening in claude.ai's callback handler, not in the MCP server or Microsoft.

Workarounds I tried (none fixed it)

• Adding realm="MCP" to the WWW-Authenticate header
• Pre-registering the OAuth client (manual ID/secret) instead of relying on DCR
• Aligning scopes_supported with the canonical resource URI (https://<fqdn>/mcp.access) so Entra v2's resource= and scope= parameters share an identifier prefix
• Both claude.ai and claude.com redirect URIs on the Entra app

If anyone from Anthropic is reading: I'd be happy to share the ofid_ reference and a Graph signIn correlation ID to whoever can correlate it against the callback handler logs. The pattern is reproducible on demand from a personal tenant.

[localden]

Thanks for the trace IDs. The ones you shared are past our log retention so I cannot pull the per-flow details, but the symptom is specific enough to narrow this down.

"code: Field required" means our OAuth callback was hit without a code query parameter in the URL. We never got a chance to exchange anything with your server; the error happens the moment your server sends the browser back to us. So this is almost always something on the authorization server side.

Things to check on your server:

• Is response_type=code set? If your server uses token or id_token, the credential goes into the URL fragment (after #) which the browser never sends to us.
• If you use response_mode=form_post, our callback only accepts a GET redirect with query params. Switch back to the default query redirect.
• When the user denies consent, does your server redirect with ?error=access_denied? Re-run the flow and approve at the consent screen to confirm.
• Double check the redirect URI you registered matches what we request exactly, including any trailing slash.
• If you have your server's logs for these attempts, the redirect URL it sent to the browser will tell us definitively which of the above it is.

If you can reproduce and share one or two fresh trace IDs we will get real per-flow events and can narrow it further.