claude.ai web + mobile connector OAuth fails against Cloudflare Access "Managed OAuth" MCP portal — Claude Code connects to the identical URL

[ai-sam-ai]

MCP server URL

https://mcp.sme.ec/mcp

Where does the issue occur?

When pressing the Connect button

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-06-07 6:07 PM AEST (Australia/Melbourne, UTC+10) = 2026-06-07 08:07 UTC

Browser and OS

Chrome 148 on Windows 10

Describe the issue

Adding our MCP server as a custom connector in claude.ai (web and mobile) fails the moment I press Connect — no Cloudflare/Access login or consent screen ever appears. The connector stays "Not connected" and shows "Authorization with the MCP server failed" with reference ofid_11fbd3c3d128f53f. The exact same server URL connects and works in Claude Code (CLI), so the server-side OAuth works for at least one Claude client.

Issue details

Error shown in claude.ai: "Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: ofid_11fbd3c3d128f53f"
Reference ID: ofid_11fbd3c3d128f53f
Affected: claude.ai web connector AND Claude mobile app. NOT affected: Claude Code (CLI) connects to the same URL fine.

It fails at the Connect button — before any authorization screen appears. I manually walked the pre-auth handshake; every server-side step succeeds:
1. GET/POST /mcp (unauth) -> 401, but with NO `WWW-Authenticate` header (the one deviation from RFC 9728 / the MCP auth spec).
2. /.well-known/oauth-protected-resource (and /mcp variant) -> 200, correct resource + authorization_servers=[https://smebusinesssupport.cloudflareaccess.com].
3. authorization-server metadata -> 200, complete: authorization/token/registration(DCR)/revocation endpoints, PKCE S256, authorization_code grant.
4. Dynamic Client Registration with redirect_uris=["https://claude.ai/api/mcp/auth_callback"] -> 201 Created, valid client_id issued (DCR accepts claude.ai's callback).
5. No Cloudflare WAF / Browser-Integrity challenge (all user-agents get 200 on discovery).

Prime suspect: because it dies before any login screen and every endpoint works when called directly, the likely trigger is the missing `WWW-Authenticate` header on the 401. Claude Code tolerates its absence (probes the .well-known path and connects); the claude.ai connector appears to require it. Please trace ofid_11fbd3c3d128f53f to confirm where the connector gives up. Likely fix: Cloudflare Access "Managed OAuth" should emit `WWW-Authenticate: Bearer resource_metadata="..."` on the 401, and/or claude.ai could fall back to probing the protected-resource well-known path like Claude Code does.

Expected behavior

Pressing Connect should run the full OAuth flow — discover metadata, register (DCR), open the Cloudflare Access login/consent screen, redirect back to https://claude.ai/api/mcp/auth_callback, exchange the code for a token, and connect — exactly as Claude Code does against this same URL and authorization server. Instead it fails instantly with no login screen.

Logs from your server

Our MCP origin (the streamable-http server behind the Cloudflare "Managed OAuth" portal) logged NOTHING for the failed connector attempts at 2026-06-07 07:43 and 08:07 UTC — the flow never reached our server. In the same window an authenticated MCP session succeeded: a sam_chat tool call at 07:52:56 UTC returned 200 OK (Claude Code, the client that works). Because Cloudflare performs the full OAuth handshake before proxying to the origin, a pre-auth failure is invisible on our side — which places the failure entirely in the pre-authorization layer (claude.ai connector <-> Cloudflare Access Managed OAuth), consistent with "fails at Connect, no login screen."

Cloudflare-side correlation logs (Zero Trust -> Access -> Logs / Authentication, and the MCP portal request logs) are available in our dashboard if helpful — happy to provide on request.

Additional context

Reference IDs from two reproductions (please correlate either):

• ofid_11fbd3c3d128f53f — 2026-06-07 07:43 UTC (5:43 PM AEST)
• ofid_bc04b84af9c20bdf — 2026-06-07 08:07 UTC (6:07 PM AEST)

Both show: "Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support."

Same server URL (https://mcp.sme.ec/mcp) connects fine in Claude Code (CLI); fails only in the claude.ai web + mobile connectors — instantly at Connect, with no login screen ever shown.

[localden]

Thanks for the report. Both flow IDs show the same pattern, and it is consistent with the Cloudflare Access login page blocking the sign-in before it completes.

On our side everything up to the authorization URL works: we discover the OAuth metadata, register a client, and build the authorization URL the browser opens. After that the flow goes quiet; the authorization code never comes back to our callback, so the token exchange never happens. From our logs we cannot distinguish a Cloudflare challenge failure from the tab simply being closed, but the trace rules out the alternatives: the auth request was built and handed off correctly, and no exchange was attempted because no code arrived.

If your auth server is behind Cloudflare Access, check whether Managed Challenge or Bot Fight Mode applies to the path users are redirected to, and whether a rule can let the sign-in page render for a person arriving from claude.ai. If you adjust that and retry, a fresh flow ID will show us the callback and exchange stages.

[jives753]

Confirming another reproduction of this.

Setup

• MCP server: Cloudflare Worker, stock remote-mcp-authless template (streamable-http at /mcp), on a workers.dev URL
• Protection: Cloudflare Access enabled via the one-click toggle on the workers.dev route, Managed OAuth ON (app → Additional settings), self-hosted Access application, Allow policy = 2 specific emails, One-time PIN login, Zero Trust Free plan
• URL: https://remote-mcp-server-authless.jared-cdb.workers.dev/mcp

Symptom (matches OP)

• Claude desktop app (Windows 11): "Authorization with the MCP server failed. You can check your credentials and permissions." — ref ofid_d42d388e72ba137e
• claude.ai web (Chrome): identical instant failure — ref ofid_bf6e58fcb0368fdf
• Both fail immediately at Connect; no Cloudflare Access login or authorization screen ever renders
• Date: 2026-06-11

Server side verified working
In a regular browser, the same URL correctly redirects to the Access login on my team domain, the email one-time PIN succeeds, and the request reaches the Worker — which returns the expected MCP transport error for browsers ("Not Acceptable: Client must accept text/event-stream"). So the Access gate, policy, and IdP all function; the failure happens in the connector's OAuth handshake before anything reaches the server.

Happy to provide more details if useful.

[lloydhazlett]

Can also reproduce (ofid_dcef4c55dd23d03e), works in Claude Code (CLI) as per the other reports.

check whether Managed Challenge or Bot Fight Mode applies to the path users are redirected to

This is ruled out in my case, security rules skip those features and the security events show requests from the Anthropic egress range 160.79.104.0/21 that are all allowed. No requests from that range are blocked or bot challenged.

[aspenas]

Another reproduction (claude.ai web, Chrome) — and I think I isolated the root cause behind "the flow goes quiet / no code comes back." It's the RFC 8707 resource parameter.

Setup: self-hosted MCP behind Cloudflare Access, Managed OAuth ON, Zero Trust Free, One-Time-PIN IdP, Allow policy on two emails. Connector URL https://wake-mcp.highline.work/mcp. Ref ofid_6a74d9400e6e51bd.

Symptom: after the Access login completes, the popup redirects to the protected-resource root (https://wake-mcp.highline.work/) instead of completing the authorization-code callback to https://claude.ai/api/mcp/auth_callback. Connector stays at 0 tools; a warm Access session doesn't change it.

Root cause: Cloudflare Access Managed OAuth requires resource on /authorize. I walked the authorize endpoint by hand (same browser, valid Access session, DCR-registered client):

GET .../cdn-cgi/access/oauth/authorization?response_type=code&client_id=<dcr>
    &redirect_uri=<...>&code_challenge=<S256>&code_challenge_method=S256
  ->  ?error=invalid_target&error_description=No+resource+parameter+found

# same request + &resource=https://wake-mcp.highline.work/mcp
  ->  ?code=<issued>     # authorization code returned immediately

So Cloudflare's /authorize works and issues a code — it just requires resource = the exact MCP server URL. If the connector's /authorize (and /token) omit the RFC 8707 resource indicator, CF returns invalid_target and no code is ever issued, which exactly matches the "goes quiet, no code comes back" trace.

This also rules out the Managed-Challenge / Bot-Fight theory (consistent with @lloydhazlett): the same browser/session completes the authorize and gets a code the instant resource is present.

Secondary observation: the protected-resource metadata that the 401 WWW-Authenticate: ... resource_metadata="..." points at advertises

"authentication_methods": ["cloudflared", "oauth"]   // cloudflared FIRST

and in my traces the popup landed on the cloudflared browser-login (/cdn-cgi/access/login/<host> → resource root), not /cdn-cgi/access/oauth/authorization. That's the browser-cookie path, not the OAuth path — which would also produce this exact symptom.

Everything else is spec-correct: DCR (RFC 7591) succeeds once the redirect_uri is allowlisted; AS metadata advertises code_challenge_methods_supported: ["S256"] and token_endpoint_auth_methods_supported incl. "none"; protected-resource resource exactly matches the connector URL; the 401 WWW-Authenticate is well-formed.

Actionable ask: confirm claude.ai's /authorize + /token requests carry the RFC 8707 resource parameter (= the exact MCP server URL) for the Cloudflare Access Managed-OAuth path. The connector-auth docs say claude.ai should already send it, so it may be getting dropped specifically here — or the cloudflared-first metadata is diverting the flow to the browser-login before the OAuth /authorize runs.

Happy to provide full traces or a live test endpoint.