Custom MCP connector OAuth fails against Azure AD/Entra ID — client appears to abort before reaching authorization_endpoint

Subject: Custom MCP connector OAuth fails against Azure AD/Entra ID — client appears to abort before reaching authorization_endpoint

Summary:
We are deploying a custom remote MCP server (https://mcp.example.com) protected via OAuth 2.1 with Microsoft Entra ID (Azure AD) as the authorization server, following the RFC 9728 Protected Resource Metadata pattern (pre-registered public client + PKCE, no Dynamic Client Registration). Every connection attempt from claude.ai fails with:

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

We have three ofid_ reference IDs and matching Entra Trace IDs from separate failed attempts today; redacted here, happy to share privately for server-side tracing if useful.

MCP server URL: https://mcp.example.com
PRM endpoint (verified working): https://mcp.example.com/.well-known/oauth-protected-resource

What we've ruled out on our end (working with our Azure tenant admin):
1. PRM metadata is correct and reachable — resource, authorization_servers, scopes_supported all verified via curl.
2. Entra app registration (client ID redacted):
- Application ID URI = https://mcp.example.com (matches MCP server exactly)
- mcp.access scope exposed and present
- Redirect URI https://claude.ai/api/mcp/auth_callback registered under SPA platform
- "Allow public client flows" enabled
- Admin-consented permissions confirmed
3. No WAF, bot protection, or CDN-layer blocking — our CloudFront distribution in front of the MCP Lambda has no WebACL attached, allows all HTTP methods including POST, and the Lambda Function URL (AuthType: NONE) has CORS configured to allow the Authorization header from any origin.
4. Our Lambda logs show ONLY the unauthenticated PRM discovery GET requests completing successfully (~2ms). No POST/token-bearing request from claude.ai's backend ever reaches our infrastructure during a failed connection attempt.
5. Entra sign-in logs show NO entry at all for any of the three failed attempts — not a failure record, nothing. Our Azure admin confirmed this by searching sign-in logs directly.

Working theory:
Point 5 strongly suggests claude.ai's backend is aborting the OAuth flow before ever calling Azure's /authorize endpoint — i.e., failing during client-side validation of the authorization server's metadata, not during the actual authorization exchange.

We compared Azure AD's standard v2.0 OIDC discovery document (https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration) against what we understand Claude's connector client expects, and noticed:
- Azure does NOT publish "code_challenge_methods_supported" in this discovery document, even though Azure AD does support S256 PKCE in practice.
- Azure does NOT publish a "registration_endpoint" (expected, since we are not using DCR).

If the Claude connector client requires "code_challenge_methods_supported" to be present and includes "S256" before proceeding with PKCE, this would explain a silent client-side abort with no corresponding Entra sign-in log entry — matching everything we've observed.

Questions for Anthropic:
1. Does the claude.ai connector client require code_challenge_methods_supported to be present in the authorization server's OIDC metadata before attempting the authorization request? If so, can this be relaxed for authorization servers (like Azure AD) that support PKCE but don't advertise it in metadata?
2. Can you trace our failed attempts server-side (we can share the ofid_ reference IDs privately) to confirm at which step the flow is failing (client-side metadata validation vs. authorize redirect vs. token exchange)?
3. Are there other known Azure AD/Entra ID-specific metadata gaps that the claude.ai connector client is strict about?

Happy to provide additional logs, our app registration manifest, or get on a call. This is blocking production rollout of OAuth-protected MCP access for our team.