modelcontextprotocol / modelcontextprotocol/python-sdk

Trailing slash in OAuthMetadata's `issuer` causes issues with clients

Offen
#1,919 5 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

auth bug P1 ready for work
Vorherrschende Sprache
Python
Sterne
24.3k
Forks
4k
Ø Merge
1 T. 1 Std.
Gemergte PRs (30 T.)
31

Beschreibung

Initial Checks
Description

In the .well-known/oauth-authorization-server endpoint and , the issuer is forced to always contain a trailing slash e.g.,

  • https://your-mcp.com/ instead of
  • https://your-mcp.com
    as a byproduct of using pydantic's AnyHttpUrl type.

This causes issues in both Google's ADK and IBM's MCP Context Forge because:

  • when building the .well-known URL, they expect a discovery issuer URL that does not contain a trailing slash; and
  • then they MUST verify that the returned metadata issuer URL is identical to the discovery issuer URL ("authorization server's issuer identifier value" in the spec) according to RFC 8414 Section 3.2; so
  • when OAuthMetadata.issuer contains the trailing slash, the discovery process is aborted.

OAuth 2.0 Authorization Server Metadata spec says that the client MUST remove trailing paths from when the issuer contains a path component:

If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI suffix between the host component and the path
component.
-- https://datatracker.ietf.org/doc/html/rfc8414#section-3.1

if the trailing / in https://example.com/ is a "path component", and should thus be stripped by the client, so I think the spec is ambiguous about the responsibilities of the client in the case where there the issuer identifier value contains a lone trailing slash.

I did note that the examples of issuer identifiers in the spec do not contain a lone trailing slash, i.e. they are https://example.com rather than https://example.com/.

For these reasons, and

  • while it's listed as the client's responsibility to remove trailing slashes from the issuer identifier,
  • I don't believe it's the server implementation's responsibility to intentionally make it harder for clients by returning a URL that do not follow the assumptions in the spec.

I think it's worth it to consider interpreting the spec as "the issuer field should not contain a trailing slash".

I also believe this issue could be similar in mechanism, but different in scope, to what is described in https://github.com/modelcontextprotocol/python-sdk/issues/1265

Example Code
# A demonstration on how AnyHttpUrl adds a trailing slash.

>>> from pydantic.networks import AnyHttpUrl
>>> x = AnyHttpUrl("http://localhost:8000")
>>> x
AnyHttpUrl('http://localhost:8000/')
>>> str(x)
'http://localhost:8000/'
>>>
Python & MCP Python SDK
Python 3.14
mcp==1.25.0

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne beim OAuthMetadata-Modell und dem Endpunkt .well-known/oauth-authorization-server und untersuche anschließend, wie Pydantics AnyHttpUrl den issuer-Wert normalisiert. Prüfe die Anforderungen von RFC 8414 und die bestehende Issue-Diskussion, bevor du entscheidest, wie ein einzelner abschließender Schrägstrich behandelt werden soll; abgeschlossen ist die Aufgabe, wenn der zurückgegebene issuer und die Discovery-URL mit den betroffenen Clients kompatibel bleiben.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
python
Bereich
api, authentication
Issue-Typ
Bug
Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Aktivitätsstatus
Aktiv
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
58/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.