anthropics / anthropics/claude-ai-mcp
Claude connector synthesizes /authorize on MCP server's own origin instead of using external Authorization Server (root-domain AS, no path)
- Langage dominant
- Aucune donnée de langage
- Étoiles
- 471
- Forks
- 76
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
## Summary
Custom MCP connector (streamable-http, RFC 9728 Resource Server delegating to an external Authorization Server) fails to connect from both Claude Desktop and Claude Code. Instead of using the `authorization_endpoint` from the external AS's discovered metadata, the client redirects the browser to `/authorize` on the **MCP server's own origin** (which doesn't implement it), resulting in a 502.
This looks related to #82, #214, and #219, but doesn't match their confirmed root causes exactly: our `authorization_servers` entry has **no path component** (it's the bare root of the Auth0 tenant domain), and #82's fix was specifically for path-component AS URLs. Filing this as a fresh, fully-reproduced report in case it's a distinct case not covered by those fixes.
## Server details
- MCP server: streamable-http transport, `mcp` Python SDK (FastMCP) v1.27.0, Resource Server mode (`token_verifier`, no `auth_server_provider`)
- Reverse proxy: Caddy (HTTP/2 to the client)
- Authorization Server: Auth0, EU region tenant (`https://jenseits-solutions.eu.auth0.com/`)
- MCP URL: `https://hermes-api.int.jenseits-solutions.com/mcp`
## Reproduction — server-side discovery chain verified correct via curl
```
$ curl -s -o /dev/null -w "%{http_code}\n" https://hermes-api.int.jenseits-solutions.com/mcp
401
$ curl -s https://hermes-api.int.jenseits-solutions.com/mcp -D -
HTTP/2 401
www-authenticate: Bearer error="invalid_token", error_description="Authentication required", resource_metadata="https://hermes-api.int.jenseits-solutions.com/.well-known/oauth-protected-resource/mcp"
$ curl -s https://hermes-api.int.jenseits-solutions.com/.well-known/oauth-protected-resource/mcp
{"resource":"https://hermes-api.int.jenseits-solutions.com/mcp","authorization_servers":["https://jenseits-solutions.eu.auth0.com/"],"bearer_methods_supported":["header"]}
$ curl -s https://jenseits-solutions.eu.auth0.com/.well-known/openid-configuration
{"issuer":"https://jenseits-solutions.eu.auth0.com/","authorization_endpoint":"https://jenseits-solutions.eu.auth0.com/authorize","token_endpoint":"https://jenseits-solutions.eu.auth0.com/oauth/token", ..., "registration_endpoint":"https://jenseits-solutions.eu.auth0.com/oidc/register", ...}
$ curl -s https://jenseits-solutions.eu.auth0.com/.well-known/oauth-authorization-server
(also 200, same data)
```
Every step of RFC 9728 discovery (401 → resource_metadata → protected-resource metadata → authorization_servers → AS's own `.well-known/openid-configuration` with a valid `registration_endpoint` for DCR) resolves correctly and independently via curl. Auth0's registration_endpoint supports Dynamic Client Registration, so no manual client should even be necessary.
## What Claude actually does
Both Claude Desktop and Claude Code (removed and re-added the connector from scratch, not a stale-cache issue) redirect the browser to:
```
https://hermes-api.int.jenseits-solutions.com/authorize?response_type=code&client_id=ScH2n602Tm23EYjIQ2z7NDvRSBGdzRl7&redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback&code_challenge=...&code_challenge_method=S256&state=...
```
i.e. `/authorize` on the **MCP server's own origin**, which returns a 502 (our server doesn't implement an authorization endpoint — it's a Resource Server, not an AS). The `client_id` is identical across multiple full reconfigurations (remove + re-add), which rules out a client-registration/caching explanation and points to the client defaulting/synthesizing this URL rather than using the discovered `authorization_endpoint`.
## Support reference
An early attempt (before this investigation, same connector/URL) surfaced this reference in the Desktop error toast:
```
ofid_08d51a464964344a
```
## Question
Is this the same root cause as #82 (which was specifically about AS URLs with a path component) despite our AS being a bare root domain, or a distinct case? Happy to provide more detail/trace IDs if useful.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Évaluation
Cette issue n'a pas encore été évaluée.