Inside the Harness: MCPs OAuth-Issuer-Bindung und warum Protokollsicherheit in String-Vergleichen lebt

Drei Zahlen, dann erkläre ich sie. Eins: Das issuer-Feld in einem OAuth-Metadokument ist ein einzelner String. Zwei: In diesem Sommer haben Atlassian, Context7 und Home Assistant jeweils MCP-Autorisierungsmetadaten ausgeliefert, bei denen dieser String nicht mit der URL übereinstimmte, von der das Dokument abgerufen wurde, und strikte Clients verweigerten die Verbindung. Drei: Der Fix, der nun in der MCP-Spezifikation ausgeliefert wird, lautet im Kern: "String vergleichen, bei Abweichung ablehnen." Das ist der ganze Mechanismus, und er schließt einen der unangenehmsten OAuth-Angriffe: den Mix-up-Angriff, der durch die Art, wie MCP deployt wird, strukturell noch problematischer wird.

Dies ist ein Inside-the-Harness-Beitrag, also gehen wir in die Leitungen: Was ist das Issuer-Binding-Problem, welche Flows betrifft es, und was verlangt das Spezifikationspaket 2026-07-28 von jedem, der einen MCP-Client oder -Server baut? Die Stateless-Transport-Änderungen derselben Version bekamen die Schlagzeilen; die Auth-Härtung bekam sechs SEPs und fast keine Aufmerksamkeit. Das ist verkehrt herum, denn wenn Sie MCP-Server mit echten Credentials betreiben, entscheidet dieser Teil darüber, ob ein verwirrter Client ein Token an die falsche Partei weitergibt.

Wichtigste Erkenntnisse - MCP kehrt die klassische OAuth-Form um: Ein Client spricht mit vielen Authorization Servers, die zur Laufzeit entdeckt werden. Genau diese Topologie ist das Ziel von Mix-up-Angriffen. - Das Spezifikationspaket 2026-07-28 umfasst sechs SEPs. Die zwei wichtigsten: SEP-2468, das den iss-Parameter in Authorization Responses nach RFC 9207 validiert, und SEP-2352, das jedes registrierte Client Credential an den Issuer bindet, der es ausgestellt hat. - Das ist nicht theoretisch. Die MCP-Endpunkte von Atlassian und Context7 haben diesen Sommer bereits Metadaten mit Issuer-Mismatch ausgeliefert und strikte Clients gebrochen; die Spezifikation holt Fehler ein, die schon in Production existieren. - iss-Validierung wird jetzt empfohlen und entwickelt sich Richtung Pflicht. Bauen Sie sie heute ein und behandeln Sie ein fehlendes iss von einem Server, der es unterstützen sollte, als Ablehnung, nicht als Schulterzucken. - Selbst bei vollständiger Umsetzung härtet dieses Paket nur die Client-zu-Server-Authentifizierung. Agent Identity, Per-Request Authorization, Delegation Provenance und Audit bleiben außerhalb des Protokolls und damit bei Ihnen.

Was passiert ist

Am 21. Mai 2026 sperrten die MCP-Maintainer den Release Candidate für die Spezifikation 2026-07-28, die finale Spezifikation erschien am 28. Juli, und SDK-Maintainer befinden sich seitdem in einem zehnwöchigen Validierungsfenster. Die meiste Diskussion drehte sich um den Stateless-Wechsel. Darunter liegt laut Tigeras detaillierter Analyse der Version ein Paket aus sechs Spec Enhancement Proposals zur Härtung der OAuth-Schicht:

Die drei Housekeeping-SEPs 2207, 2350 und 2351 sind Klarstellungen, und Klarstellungen in Auth-Spezifikationen sind wichtig: Wenn sich zwei SDKs nicht darüber einig sind, wo ein Metadokument liegt, ist das ein Interop-Ausfall und keine Fußnote. Aber das tragende Paar sind 2468 und 2352. Beide beantworten dieselbe Frage: Wie weiß ein Client, mit welchem Server er tatsächlich spricht?

Das MCP-Spezifikationspaket 2026-07-28 enthält sechs SEPs zur OAuth-Härtung: Issuer-Validierung (2468), issuer-gebundene Credentials (2352), Deklaration des Client-Typs in Dynamic Client Registration (837), plus dokumentierte Refresh Tokens (2207), Scope-Akkumulation (2350) und Discovery-Verhalten (2351), laut Tigeras Analyse. Der Release Candidate wurde am 21. Mai gesperrt, die finale Spezifikation erschien am 28. Juli 2026.

Das Schwachstellenmodell: ein Client, viele Issuer

Klassisches OAuth nimmt viele Clients und einen Authorization Server an: Tausende Apps, ein Identity Provider, ein Token Issuer. Mix-up-Angriffe, bei denen ein Client dazu gebracht wird, eine Authorization Response dem falschen Server zuzuordnen, waren ein Nischenthema, weil die meisten Clients immer nur mit einem Issuer sprachen.

MCP dreht das vollständig um. Ein Client, die Host-Anwendung, spricht mit vielen MCP-Servern, die jeweils von einem anderen Authorization Server vorgeschaltet sein können, zur Laufzeit entdeckt und oft per Dynamic Client Registration spontan registriert werden. Die Spezifikationsautoren sagen es direkt: Das Issuer-Validation-SEP zielt auf "a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern", wie Tigeras Beitrag zitiert. Wenn Ihr Client gleichzeitig Registrierungen bei einem Dutzend Authorization Servers hält, muss ein Angreifer keine Kryptografie brechen. Er muss Ihren Client dazu bringen, eine Antwort dem falschen Server zuzuordnen.

So sieht das aus. Der Host Ihres Agents befindet sich mitten im Flow mit dem ehrlichen Server A, als eine Antwort eintrifft, die tatsächlich vom vom Angreifer kontrollierten Server B stammt. Ohne Issuer-Prüfung kann der Client den Exchange gegen B abschließen und dabei den Authorization Code leaken, oder von B ausgestellte Tokens akzeptieren und weiterreichen. RFC 9207, der 2021 veröffentlichte Fix für klassisches OAuth, fügte einen expliziten iss-Parameter zu Authorization Responses hinzu, damit der Client alles von einem unerwarteten Issuer ablehnen kann, und SEP-2468 bringt diese Anforderung in MCP. SEP-2352 behandelt die leisere Hälfte: Credentials. Zuvor konnte ein Client eine von Issuer A ausgestellte Client ID halten und, wenn eine Resource zu Issuer B migrierte, As Credential bei B präsentieren. Manchmal funktionierte das, und "manchmal funktioniert es" ist keine Eigenschaft, die man in einem Auth-System haben möchte. Daher verlangt 2352, Registrierungen pro Authorization Server zu halten, an den Issuer-Wert zu binden und bei Migration neu zu registrieren.

Das ist auch nicht der erste Versuch gegen diese Angriffsklasse. Die Spezifikationsrevision 2025-06-18 machte Resource Indicators nach RFC 8707 verpflichtend, damit Tokens für genau einen bestimmten Server ausgestellt werden, und die MCP Authorization Specification verbietet bereits, Tokens für andere Resources zu akzeptieren oder downstream weiterzureichen. Das Paket 2026-07-28 setzt dieselbe Richtung fort: weniger Vertrauen per Default, mehr explizite Bindung. Wenn Sie meinen Beitrag MCP versus API gelesen haben, ist das der Preis der dort beschriebenen Flexibilität: Runtime Discovery macht MCP komponierbar und erzeugt zugleich diese Identity-Fragen.

MCPs One-Client-Many-Servers-Topologie ist genau das Deployment-Muster, auf das Mix-up-Angriffe zielen: Ein Angreifer bricht nicht die Kryptografie, sondern bringt den Client dazu, eine Response oder ein Credential dem falschen Authorization Server zuzuordnen. SEP-2468 bindet Responses über RFC 9207s iss-Parameter an Issuer; SEP-2352 bindet registrierte Credentials an den Server, der sie ausgestellt hat, laut Tigeras Analyse und RFC 9207.

Die Spezifikation holt Production-Fehler ein

Wenn das abstrakt klingt, ist es das nicht. Der Issuer-String scheitert diesen Sommer bereits in realen MCP-Deployments, und strikte Clients stolpern schon darüber.

Im Juli stellten Nutzer des opencode-Clients fest, dass OAuth zu Atlassians Rovo MCP Server bei Discovery scheiterte. Die Protected-Resource-Metadaten kündigten korrekt einen tenant-spezifischen Authorization Server an, aber das dort ausgelieferte Metadokument deklarierte den bloßen gemeinsamen Issuer https://auth.atlassian.com statt des Tenant-Pfads, von dem es abgerufen wurde. RFC 8414 Abschnitt 3.3 sagt, der issuer-Wert müsse exakt der URL entsprechen, mit der die Metadaten abgerufen wurden, abzüglich des .well-known-Suffixes. Opencodes strikte Validierung lehnte die Antwort daher korrekt ab und blockierte Login vollständig: ein Atlassian-seitiger Spec-Compliance-Bug, bestätigt gegen Live-Endpunkte. Context7s MCP-Endpunkt hatte im Juni einen verwandten Fehler, bei dem der angekündigte Authorization Server und der Metadata Issuer auf einer Clerk-Subdomain nicht übereinstimmten, und das offizielle MCP Go SDK verweigerte den Flow. Home Assistants Metadaten ließen das Issuer-Feld vollständig weg, wodurch MCP-Clients auf andere Weise brachen.

Keiner dieser drei Fälle war ein Mix-up-Exploit; es waren Interop-Fehler. Aber genau das ist der Punkt. Derselbe String-Vergleich, der den Fake-Server eines Angreifers blockiert, blockiert auch einen schlampigen echten Server. Das Ökosystem wird also deutlich weniger tolerant gegenüber Metadaten, die immer falsch waren und bisher durchgingen. WorkOS' Beitrag zu Mix-up-Angriffen bringt den operativen Punkt gut auf den Punkt: Viele OAuth-Libraries lassen RFC-9207-Prüfung weiterhin standardmäßig aus und verweisen auf CVE-2026-59208 als Fall, in dem Account-Lookups auf den bestätigten Issuer beschränkt werden sollten, statt einen sub-Claim global zu matchen. Ich würde diese CVE-Referenz als von WorkOS berichtet und nicht unabhängig verifiziert behandeln, aber das defensive Prinzip ist ohnehin Standardpraxis.

Reale MCP-Deployments sind diesen Sommer bereits an Issuer-Validierung gescheitert: Atlassians Rovo MCP Server liefert Metadaten, deren Issuer nicht mit der Tenant-URL des Abrufs übereinstimmt (opencode issue #39332), Context7s Endpunkt kündigte einen Authorization Server an, während die Metadaten einen anderen deklarieren (Context7 issue #2723), und Home Assistant ließ das Issuer-Feld vollständig weg. RFC 8414 Abschnitt 3.3 verlangt, dass der Issuer-Wert exakt der Retrieval URL entspricht, daher lehnten strikte Clients alle drei korrekt ab.

Was Implementierer tun müssen

Wenn Sie einen MCP-Client pflegen:

1. Validieren Sie iss ab sofort bei jeder Authorization Response. Lehnen Sie Mismatches gegenüber dem Issuer ab, mit dem Sie sich gerade im Flow befinden. Wenn der Server RFC-9207-Unterstützung ankündigt, aber den Parameter weglässt, lehnen Sie auch das ab. Die Spezifikation ist klar, dass die Ablehnung eines fehlenden iss in einer künftigen Version erwartet wird, also behandeln Sie es heute als Pflicht.

2. Partitionieren Sie Registration State pro Authorization Server. Jede Client ID, jedes Secret und jedes Refresh Token wird gegen den Issuer gespeichert, der es ausgestellt hat. Wenn Protected-Resource-Metadaten einer Resource auf einen neuen Authorization Server zeigen, registrieren Sie neu; spielen Sie das alte Credential niemals erneut ab.

3. Deklarieren Sie application_type bei Dynamic Client Registration. SEP-837 behebt die Fehlerklasse, in der ein Desktop- oder CLI-Client standardmäßig als web behandelt und wegen seiner localhost Redirect URI abgelehnt wird. Ein Feld, eine reale Bug-Klasse weniger.

4. Beschränken Sie Account-Lookups auf den Issuer. Ein sub-Claim darf Accounts nur innerhalb des Namespace des tatsächlich validierten Issuers matchen. Niemals global matchen.

Wenn Sie einen MCP-Server oder einen vorgeschalteten Authorization Server betreiben: Liefern Sie Metadaten aus, deren issuer exakt der URL entspricht, von der sie abgerufen werden, einschließlich Tenant-Pfad; implementieren Sie Protected-Resource-Metadaten nach RFC 9728 und validieren Sie weiterhin, dass Tokens speziell für Ihre Resource ausgestellt wurden. Und wenn Sie Agents selbst hosten und dabei eine wachsende Liste von MCP-Servern anbinden, wird die Fleet-Mathematik relevant: N Agents mal M Servers bedeutet N mal M issuer-gebundene Registrierungen. Bei zehn Agents ist das ein Spreadsheet, bei hundert ein Registry-System, und die Spezifikation hat keine Meinung zu Registries. Dieser Teil liegt bei Ihrer Plattform.

Implementierer müssen iss in Authorization Responses validieren, Mismatches und, wo unterstützt, Omissions ablehnen, Credentials nach Issuer partitioniert speichern und bei Migration neu registrieren, application_type bei Dynamic Client Registration deklarieren und Account-Lookups auf den validierten Issuer beschränken, laut Tigeras SEP-Analyse und WorkOS' Mix-up-Guidance. Tier-1-SDKs sollen die Unterstützung innerhalb des zehnwöchigen Validierungsfensters der Spezifikation ausliefern.

Was die Spezifikation weiterhin nicht beantwortet

Lesen Sie das Paket noch einmal und achten Sie darauf, was alle sechs SEPs gemeinsam haben: Sie härten den Exchange zwischen einem OAuth-Client und einem Authorization Server. Das war nötig. Aber wie Tigeras Analyse klar sagt, authentifiziert das Token den Client, nicht den Agent. Zweihundert Agents hinter einem Host teilen eine Client Identity; Issuer Binding sagt nichts darüber, welcher Agent, in wessen Auftrag, aufgrund welcher Entscheidung hinter dem Client steht. Scopes sind Admission, keine Per-Request Policy. Delegation Chains, Agent ruft Agent ruft Server, können bei jedem Hop OAuth-sauber und End-to-End dennoch nicht accountable sein. Und nichts im Paket verlangt, dass irgendjemand all das aufschreibt. Das ist eine korrekte Scope-Entscheidung für ein Protokoll und eine unvollständige Antwort für ein Enterprise.

Ich sage das nicht, um die Arbeit kleinzureden. MCP ohne Issuer-Validierung war HTTP ohne Certificate Checking, und diese Lücke schließt sich jetzt. Aber die vier Lücken, Agent Identity, Per-Request Authorization, Delegation Provenance und Audit, sind die Governance-Schicht. Sie kommen nicht dadurch, dass man auf die Spezifikation wartet. Es sind dieselben Lücken, die ich mit Kunden bei Agent Governance durcharbeite, und sie werden von der Umgebung um den Agent herum erzwungen oder von niemandem.

FAQ

Was ist das MCP OAuth Issuer-Binding-Problem?

MCP-Clients sprechen mit vielen Authorization Servers, die zur Laufzeit entdeckt werden. Dadurch werden sie anfällig für Mix-up-Angriffe: Eine Response oder ein Credential wird dem falschen Server zugeordnet. Die Spezifikation 2026-07-28 behebt das, indem Clients den iss-Parameter in Authorization Responses validieren müssen, SEP-2468 nach RFC 9207, und jedes registrierte Credential an seinen Issuer binden müssen, SEP-2352.

Ist das eine Schwachstelle in MCP selbst?

Es ist eine Schwachstellenklasse, die durch das Deployment-Muster des Protokolls besonders relevant wurde und nun auf Spec-Ebene geschlossen wird. Die Production-Fehler dieses Sommers, Atlassian, Context7 und Home Assistant mit issuer-mismatched Metadata, waren Implementierungsbugs. Sie zeigen aber, wie fragil das unvalidierte Modell war. Strikte Validierung ist jetzt die Baseline.

Welche Flows sind betroffen?

Authorization-Code-Flows mit jedem Client, der bei mehr als einem Authorization Server registriert ist, Dynamic Client Registration über mehrere Server, Credential-Nutzung nach Migration einer Resource zwischen Authorization Servers und Metadata Discovery über .well-known-Dokumente. Single-Server-Deployments waren nie das Problem; das Risiko entsteht aus der Multi-Server-Topologie von Agents.

Wann wird das verpflichtend?

Die Spezifikation 2026-07-28 ist final, SDK-Support landet innerhalb eines zehnwöchigen Validierungsfensters seit dem Release-Candidate-Lock im Mai, und die Spezifikation sagt ausdrücklich, dass die Ablehnung von Responses ohne iss in einer zukünftigen Version erwartet wird. Behandeln Sie es in allem, was Sie heute bauen, als verpflichtend.

Fazit

OAuth-Sicherheit besteht zum großen Teil aus langweiligen String-Vergleichen mit Konsequenzen, und MCP hatte gerade seine Abrechnung mit dieser Tatsache. Das Paket 2026-07-28 importiert einen fünf Jahre alten OAuth-Fix in ein Protokoll, dessen One-Client-Many-Servers-Form ihn dringend nötig machte, genau als reale Deployments in freier Wildbahn an dieser Prüfung zu scheitern begannen. Aktualisieren Sie Ihre SDKs, validieren Sie iss, binden Sie Ihre Registrierungen. Stellen Sie danach die Frage, die die Spezifikation zu Recht nicht beantwortet: Wenn ein von Ihnen ausgestelltes Token für einen Tool Call verwendet wird, den Sie nie genehmigt hätten, präsentiert von einem Agent, den Sie nicht benennen können, wer erkennt es, und wo ist der Nachweis? Diese Antwort kommt nicht aus einer Spezifikation. Sie kommt aus dem Harness, das Sie darum bauen.

Wenn Sie Auth und Identity für ein MCP-Deployment sortieren, ist das ein Gespräch, das ich regelmäßig mit Kunden führe. Kontakt aufnehmen.

Quellen

• Tigera, "MCP's Auth Hardening: What the Six New OAuth SEPs Fix, and What They Still Don't": https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (veröffentlicht 2026-07-28, abgerufen 2026-08-29)

• WorkOS, "OAuth mix-up attacks and RFC 9207: The issuer check that never made it to token exchange": https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (veröffentlicht 2026-07-20, abgerufen 2026-08-29)

• Model Context Protocol, Authorization specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (veröffentlicht 2025-11-25, abgerufen 2026-08-29)

• RFC Editor, RFC 9207, "OAuth 2.0 Authorization Server Issuer Identification": https://www.rfc-editor.org/rfc/rfc9207.html (veröffentlicht 2021-12-16, abgerufen 2026-08-29)

• opencode repository, issue #39332, "MCP OAuth: Atlassian auth fails - RFC 8414 issuer mismatch": https://github.com/anomalyco/opencode/issues/39332 (veröffentlicht 2026-07-28, abgerufen 2026-08-29)

• Context7 repository, issue #2723, "OAuth metadata issuer mismatch for MCP OAuth endpoint": https://github.com/upstash/context7/issues/2723 (veröffentlicht 2026-06-05, abgerufen 2026-08-29)

• Home Assistant Core, issue #147059, missing issuer in OAuth metadata: https://github.com/home-assistant/core/issues/147059 (veröffentlicht 2025-06-17, abgerufen 2026-08-29)

• modelcontextprotocol/modelcontextprotocol repository: https://github.com/modelcontextprotocol/modelcontextprotocol (abgerufen 2026-08-29)