CRITICAL: claude.ai MCP connector OAuth completes but Bearer token never sent to server

[daveladouceur]

Priority: CRITICAL / URGENT

Summary

claude.ai's MCP connector completes the full OAuth 2.1 authorization_code + PKCE flow successfully (Dynamic Client Registration → authorize → token exchange), but never sends the subsequent MCP request with the Bearer token. The server issues a valid access_token, but claude.ai reports "Authorization with the MCP server failed" without ever attempting an authenticated request.

This affects ALL self-hosted remote MCP servers using OAuth. The server-side implementation is correct — verified by simulating the full flow with curl through the same tunnel.

Environment

• Self-hosted MCP server behind Cloudflare named tunnel
• Transport: Streamable HTTP (POST for JSON-RPC, GET for SSE)
• Protocol version: 2025-03-26
• Server correctly implements: RFC 9728 (Protected Resource Metadata), RFC 8414 (Authorization Server Metadata), RFC 7591 (Dynamic Client Registration), PKCE (S256)

Reproduction

Every attempt follows this exact sequence (from server logs):

POST /gws → 200 (initialize succeeds)
GET /.well-known/oauth-protected-resource/gws → 404
GET /.well-known/oauth-protected-resource → 404  
GET /.well-known/oauth-authorization-server → 404
POST /register → 201 (client registered successfully)
GET /authorize → 302 (code issued, redirect to claude.ai callback)
POST /token → 200 (access_token issued, PKCE verified ✓)
... silence. No authenticated MCP request ever arrives.

Claude.ai then displays: "Authorization with the MCP server failed"

Proof the server works

Full OAuth + authenticated MCP call via curl through the same tunnel:

# Register → Authorize → Token (all succeed)
# Then:
curl -X POST https://mcp.prtrust.fund/gws \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
# Returns: 6 tools successfully

The server is reachable, OAuth is correct, authenticated MCP calls work. claude.ai just never sends step 8.

Variations tested (all fail identically)

Version	What we tried	Result
v1.5.19	well-known 200 + OAuth enabled, resource=/sse	Token issued, never used
v1.5.20	Added 401 gate on POST /sse for tunnel requests	claude.ai skipped 401, went straight to /register
v1.5.22	Path-aware well-known (resource matches connector URL)	Token issued, never used
v1.5.25	Accept client_secret as Bearer + client_credentials grant	Token issued, never used
v1.5.27	404 ALL OAuth endpoints	"Couldn't reach server"
v1.5.28	404 well-known only, OAuth endpoints live	Token issued, never used
v1.5.29	404 /register too	"Couldn't reach server"
v1.5.30	Fresh domain (mcp.prtrust.fund, no cached state)	Token issued, never used

PKCE verification proof (from server logs)

OAuth /token: grant_type=authorization_code code=a9693dc3… verifier=present
OAuth /token: PKCE: challenge=0Qdw7BNb6SUK… computed=0Qdw7BNb6SUK… match=true
OAuth: token issued for 0b5d725f1b047d1757c3b6bb3e299f2f (token=ab956009…)

PKCE passes. Token is valid. claude.ai has the token. It never uses it.

Support references

• ofid_5b4f176052475e66
• ofid_24385e3ebac39bf8
• ofid_00912162dce5872c
• ofid_3ddc9e36fada07fa
• ofid_42c4f5ce4ebf5530
• ofid_0124fba879402e77
• ofid_f8bab433728a98e9
• ofid_0c0e836314b4995f
• ofid_5211d10fd69c4ff0

Related issues

• Claude.ai MCP Connector Not Sending Bearer Token After OAuth Completion modelcontextprotocol/modelcontextprotocol#2157
• Multiple reports on community forums of the same "Authorization failed" pattern
• Cloudflare community thread: "Authorization with the MCP server failed" (WAF ruled out)

Impact

Cannot use any self-hosted MCP server with claude.ai web interface. Claude Code CLI works perfectly with the same server (OAuth completes and Bearer token is correctly sent). This blocks all remote MCP integrations for users who need claude.ai web access.

Expected behavior

After receiving a valid access_token from POST /token, claude.ai should retry the original MCP request with Authorization: Bearer <token> header.

Actual behavior

claude.ai receives the access_token, discards it, and reports "Authorization with the MCP server failed" without attempting any authenticated request.

[raye-deng]

This is a critical issue – OAuth flow completes successfully but the Bearer token never gets used in subsequent requests. We've seen a similar pattern in production where AI-generated API clients complete all the setup steps correctly but fail to actually use the credentials in the actual API calls.

The tricky part is that these failures are often silent: the OAuth response looks valid (200 OK with access_token), the code path for authorization completes without exceptions, but the actual API request goes out unauthenticated or with the wrong headers.

Traditional static analysis tools miss this because they can't validate runtime protocol behavior. We've been adding runtime protocol validation as a PR check to catch these classes of issues.

For anyone debugging similar API integration issues, it's worth adding a protocol-level validation step in your CI pipeline. You can test this pattern with: npx @opencodereview/cli scan . --sla L1

Thanks for flagging this – getting OAuth right is hard enough without silent token-handling bugs.

[daveladouceur]

Update — still broken, now with fully protocol-compliant server (v1.5.37)

Rebuilt the OAuth 2.1 implementation from scratch following the spec exactly. All server-side issues from the original report are fixed. The bug is confirmed client-side.

What was fixed server-side (v1.5.36–v1.5.37)

• Added proper 401 gate with WWW-Authenticate: Bearer realm="MCP", resource_metadata="<absolute-url>"
• Public client registration — no client_secret, token_endpoint_auth_methods_supported: ["none"]
• Mandatory PKCE S256 on both /authorize and /token
• Cache-Control: no-store on all OAuth responses
• OAuth endpoints at domain root (/register, /authorize, /token)
• Absolute URLs in all metadata and headers

Same result — token issued, never used

POST /clauth           → 401 + WWW-Authenticate ✅
GET  /.well-known/...  → 200 (resource metadata) ✅
GET  /.well-known/...  → 200 (auth server meta)  ✅
POST /register         → 201 (public client)     ✅
GET  /authorize        → 302 → claude.ai callback ✅
POST /token            → 200 (access_token)       ✅
POST /clauth + Bearer  → NEVER ARRIVES            ❌

New ofid_ references

• ofid_870bc239f1fc3342 (clauth endpoint)
• ofid_eb53b996a97a28a4 (gws endpoint)

Confirmed working with same server

• test-mcp-oauth.mjs passes all 8 stages through Cloudflare tunnel
• Claude Code CLI works end-to-end (claude mcp add --transport http)

This is the same bug as anthropics/claude-ai-mcp#136 — confirmed cluster across multiple independent servers including Vercel's own MCP. The claude.ai OAuth proxy completes token exchange but never sends the authenticated MCP request.

This is blocking production MCP infrastructure. Please escalate to the claude.ai client engineering team.

[daveladouceur]

Workaround found — noauth on fresh domain

While waiting for the OAuth proxy fix, we found a working workaround:

Use a fresh domain that has never exposed OAuth endpoints. Claude.ai connects directly — same pattern as any MCP server without auth (e.g., regen-media).

What we discovered

• regen-media MCP (media.regendevcorp.com) works on claude.ai because it never had OAuth endpoints
• Any domain that has ever exposed /.well-known/oauth-authorization-server appears to be permanently cached as "OAuth-required" in Anthropic's proxy — even after removing those endpoints
• Domains we burned trying OAuth: clauth.prtrust.fund, mcp.prtrust.fund, vault.regendevcorp.com

The fix

1. Create a fresh subdomain (e.g., clauth.regendevcorp.com)
2. CNAME it to the same Cloudflare tunnel (proxied)
3. In the MCP server, check the Host header — if it's a "noauth host," return 404 for all /.well-known/* and OAuth endpoints (/register, /authorize, /token), and skip the 401 gate
4. Claude.ai connects directly to the MCP endpoint without triggering OAuth

Config pattern (Node.js)

const NOAUTH_HOSTS = ["clauth.regendevcorp.com", "fs.regendevcorp.com"];
const host = (req.headers.host || "").split(":")[0].toLowerCase();

// Block OAuth discovery on noauth hosts
if (NOAUTH_HOSTS.includes(host) && reqPath.startsWith("/.well-known/")) {
  return res.writeHead(404).end('{"error":"not_found"}');
}

// Block OAuth endpoints on noauth hosts  
if (NOAUTH_HOSTS.includes(host) && ["/register", "/authorize", "/token"].includes(reqPath)) {
  return res.writeHead(404).end('{"error":"not_found"}');
}

// Skip 401 gate on noauth hosts
if (!NOAUTH_HOSTS.includes(host) && !validToken) {
  return res.writeHead(401, { "WWW-Authenticate": `Bearer resource_metadata="..."` }).end();
}

Result

We now have 27 MCP tools (credential vault + Google Workspace + filesystem) working on claude.ai through the noauth domain. The OAuth endpoints still work on the original domain for Claude Code CLI.

This is a temporary workaround — when the OAuth proxy is fixed, we can switch back to the authenticated domains. But for anyone else blocked by this bug, fresh domain + suppress OAuth = working connector.

[danigrubi]

This affects me too as a Pro user with Home Assistant + Nabu Casa

[odoremieux]

Same problem