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)

Ouverte
#706 1 commentaire 1 réaction 0 personnes assignées Voir sur GitHub
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.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.