Custom connector completes DCR + authorize + /token (200) then never contacts the MCP endpoint — "Authorization with <connector> failed"

## Summary

A custom remote MCP connector completes the **entire** OAuth flow against our server — dynamic client registration, authorize redirect, Google sign-in, and `POST /token` returning **200** — and then claude.ai's backend never sends another request. The UI shows *"Authorization with `` failed. You can check your credentials and permissions."*

Two other Anthropic clients complete the identical flow against the **same server on the same day** and go on to call tools: **Claude Code 2.1.172** and the **official MCP Python SDK** (`OAuthClientProvider` + `streamablehttp_client`). Anthropic support reviewed our server-side logs and suggested filing here with the `ofid_` references so the connector's post-token behavior can be traced server-side.

Hostname redacted here for privacy; it is on file with support under the references below and can be shared privately.

## Support references

`ofid_d30d22f2f2b51ff5`, `ofid_cc2e9efecfc9736b`, `ofid_7d77761a334a1c52`

## Server

- MCP endpoint: `https://mcp./sse` — serves **both** Streamable HTTP (`POST`) and legacy HTTP+SSE (`GET`).
- Self-hosted OAuth 2.1 authorization server at `https://mcp.` (same origin), discovered via RFC 9728: unauthenticated `POST /sse` → `401` with `WWW-Authenticate: Bearer resource_metadata="https://mcp./.well-known/oauth-protected-resource", scope="mcp"`.
- PRM: `{"resource":"https://mcp./sse","authorization_servers":["https://mcp."]}` — `resource` equals the connector URL exactly (lowercase, no trailing slash).
- AS metadata: `authorization_code` + `refresh_token`; PKCE `S256` only; `token_endpoint_auth_methods_supported: ["none"]`; `scopes_supported: ["mcp"]`; `authorization_response_iss_parameter_supported: true`.
- DCR (RFC 7591) issues public clients (`token_endpoint_auth_method: none`, no client secret).
- Tokens: JWTs with `aud` = `https://mcp./sse` (exactly the RFC 8707 `resource` the connector sends) and `iss` = the AS issuer; `expires_in: 3600`; refresh tokens issued; token responses carry `Cache-Control: no-store` / `Pragma: no-cache`.
- No redirects on the HTTPS endpoint (GET/POST/HEAD, trailing slash, mixed case all answer directly). `/token` latency ~4 ms.
- CDN bot protection ruled out: the connector's own discovery/registration/token requests all reach the origin; non-browser HTTP clients from residential and cloud egress reach the origin too.

## What the connector does (every attempt, all 2026-09-01 UTC)

1. `POST /sse` (no token) → 401 + `WWW-Authenticate` as above
2. `GET /.well-known/oauth-protected-resource` → 200; `GET /.well-known/oauth-authorization-server` → 200
3. `POST /register` → 201, **twice**, ~1 s apart (`client_name: "Claude"`, `redirect_uris: ["https://claude.ai/api/mcp/auth_callback"]`, `token_endpoint_auth_method: "none"`, `grant_types: ["authorization_code","refresh_token"]`, `scope: "mcp"`)
4. Browser: `GET /authorize?response_type=code&client_id=…&redirect_uri=https://claude.ai/api/mcp/auth_callback&code_challenge=…&code_challenge_method=S256&state=…&scope=mcp&resource=https://mcp./sse` → 302 to Google
5. Google sign-in succeeds → our callback issues a code → 302 to `https://claude.ai/api/mcp/auth_callback?code=…&state=…&iss=…`
6. `POST /token` from `python-httpx/0.28.1` with fields `client_id, code, code_verifier, grant_type, redirect_uri, resource` (`resource=https://mcp./sse`, no client authentication, `Accept: application/json`) → **200** `{"access_token":"…","token_type":"Bearer","expires_in":3600,"refresh_token":"…","scope":"mcp"}`
7. **Nothing further.** No `POST /sse`, no `GET /sse`, no refresh — the token is never used. UI reports the authorization failure.

| Attempt window (UTC) | DCR `client_id` used at /authorize | `/token` |
|---|---|---|
| 19:41:23 – 19:41:28 | `mcp-943c9dda6b80478390b65fff91f65814` | 200 |
| 19:43:23 – 19:43:27 | `mcp-2e2fe9b9a647456a952b89e924f9794b` | 200 |
| 20:12:31 – 20:12:35 | `mcp-f76d6d2fbd1d4411b34f0bab6c27203a` | 200 |
| 20:13:29 – 20:13:32 | `mcp-451dee42a36c46c99e2b585d51369aa0` | 200 |
| 20:13:59 – 20:14:02 | `mcp-c4cd436dcbca4da6aaf945ba2573fcc2` | 200 |
| 20:25:43 – 20:25:47 | `mcp-fe25e98dcc404ff49b98be7366cd27eb` | 200 |

## Controls (same server, same day)

- **Claude Code 2.1.172**, 20:27:22–20:27:27 UTC, `client_id mcp-d5210083dce6426191cb8f9b036cb111`, `redirect_uri http://localhost:3118/callback`: identical discovery → DCR → authorize → Google → `/token` 200, then immediately `POST /messages/` (legacy SSE transport) and `ListToolsRequest` — **works**.
- **Official MCP Python SDK** (`OAuthClientProvider` with `streamablehttp_client`, `token_endpoint_auth_method: none`, redirect `https://claude.ai/api/mcp/auth_callback`, only the Google screen stubbed): DCR → authorize → `/token` 200 → `initialize` (protocol 2025-11-25) → `tools/list` → `tools/call` — **works**.

## Ask

Please trace what the claude.ai connector backend does after receiving the 200 token response for the client IDs / timestamps above. Possibly related: #215, #690.

The issue names no repository files, tests, or implementation entry points. Start by reproducing the documented discovery, DCR, authorize, and /token sequence using the cited ofid_ references and compare it with the Claude Code and MCP Python SDK controls. Done means identifying what claude.ai does after the 200 token response and why it reports authorization failure without contacting the MCP endpoint.

Vom Indexierungsmodell aus dem Issue-Text verfasst.