anthropics / anthropics/claude-ai-mcp

Custom connector: OAuth completes (token 200) but no authenticated MCP request ever arrives — all four causes from #125 ruled out with full edge logs (ofid_dde44effd7bdb79c)

未關閉
#905 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
auth bug server-developer-report
主要語言
沒有語言資料
星號
471
分支
76
PR 合併指標
30 天內沒有已合併 PR

描述

### MCP server URL

https://eshop.thestrongest.mk/wp-json/mcp/novamira-oauth

### 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-08-20 18:08 CEST

### Browser and OS

Chrome on Windows 11

### Describe the issue

Adding a custom MCP connector on claude.ai Web fails with "Authorization
with the MCP server failed." The server-side OAuth flow completes cleanly
every time. After /token returns 200, no authenticated request ever arrives
at the MCP endpoint.

I have full edge-level logs (Wordfence Live Traffic in "all traffic" mode),
so I can confirm nothing is being filtered on my side.

## Timeline of a failed attempt (2026-08-20, CEST)

6:07:50 POST /wp-json/mcp/novamira-oauth 200 (unauth probe)
6:07:52 GET /.well-known/oauth-protected-resource 200
6:07:53 GET /.well-known/oauth-authorization-server 200
6:07:54 POST /wp-json/novamira/v1/oauth/register 200
6:08:04 POST /wp-json/novamira/v1/oauth/token 200 (valid token issued)
-> no further requests from 160.79.106.x

Client UA: python-httpx/0.28.1
Source IPs: 160.79.106.177 (discovery + register), 160.79.106.179 (token)

Database confirms: authorization code issued and consumed, valid access
token issued with scope ["mcp"], not revoked, last_used_at = null.

## Repeated double registration

On every attempt claude.ai registers TWO OAuth clients about 6 seconds
apart. The second completes the flow and receives a valid token; the first
is never used (last_used_at = null). This repeats identically each time.

## All four causes from #125 ruled out

1. Firewall / bot protection — ruled out. Wordfence Live Traffic in
"all traffic" mode shows every request from 160.79.106.x returning 200,
none blocked, none rate-limited. Cloudflare passes all requests, no WAF
events logged.
2. Non-443 HTTPS port — not applicable, standard HTTPS.
3. Hostname resolves publicly — confirmed, your backend reached the server
and the requests are in my logs.
4. Server rejects the post-OAuth handshake — cannot apply: the MCP
initialize request with Authorization: Bearer never arrives at all.
There is no non-2xx to reject, because there is no request.

## Environment

Stack: Novamira 1.11.3, WordPress 6.9.4, PHP 8.3.33
Edge: Cloudflare + Wordfence
A records: 172.67.208.224, 104.21.85.180

The same server connects and works correctly through Claude Desktop.
This is specific to the claude.ai Web connector.

## Related

- #769 — same symptom on a self-hosted n8n server, still open, reproduced
across 2+ weeks with 3 ofid refs, and reproduces with the reverse proxy
removed entirely.
- #879 — same symptom, but resolved as a CNAME-vs-A-record edge routing
issue at the reporter's host. Not applicable here: your requests
demonstrably arrive and are in my edge logs with 200 responses.
- #680, #802, #888, #315, #393, #423, #155 — same post-token silence.

### Issue details

```shell
Error reference from the claude.ai error toast: ofid_dde44effd7bdb79c

The pop-up in claude.ai reads: "Authorization with the MCP server failed.
You can check your credentials and permissions."

The connector appears in Settings > Connectors with a warning icon and a
"Reconnect" button. Pressing Reconnect reproduces the exact same sequence
every time, including the double client registration.

Three attempts total, identical result each time.
```

### Expected behavior

After the token exchange returns 200, claude.ai should send an MCP
initialize request to the MCP endpoint with the Authorization: Bearer
header, then mark the connector as connected. Instead no such request is
ever made, and the connector is marked as failed.

### Logs from your server

```shell
Wordfence Live Traffic, "all traffic" logging mode, 2026-08-20 CEST:

6:07:50 POST /wp-json/mcp/novamira-oauth 200 python-httpx/0.28.1 160.79.106.177
6:07:52 GET /.well-known/oauth-protected-resource 200 python-httpx/0.28.1 160.79.106.177
6:07:53 GET /.well-known/oauth-authorization-server 200 python-httpx/0.28.1 160.79.106.177
6:07:54 POST /wp-json/novamira/v1/oauth/register 200 python-httpx/0.28.1 160.79.106.177
6:08:04 POST /wp-json/novamira/v1/oauth/token 200 python-httpx/0.28.1 160.79.106.179

No further requests from 160.79.106.x after 6:08:04. Every request logged,
none blocked, none rate-limited, no WAF events.

Novamira plugin self-diagnostic (OAuth mode): all checks pass.
```

### Additional context

The plugin's own diagnostic recommends allowing /wp-json/mcp/novamira and
/.well-known/oauth-* through the CDN/WAF layer. I verified via edge logs
that nothing is being filtered — all requests from 160.79.106.x return 200,
so no allowlisting is needed on my side.

Happy to run any additional test against this server, or to grant temporary
access for debugging if that helps.

貢獻指南

這個儲存庫沒有索引到貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。