Zusammenfassung

  • RFC 9207 gibt einem OAuth-Client einen eng begrenzten Beleg: Der Issuer in der Autorisierungsantwort muss mit dem für diese Anfrage gespeicherten Issuer identisch sein. Eine Abweichung beendet den Ablauf, bevor der Code an einen falschen Endpoint gelangt.
  • iss identifiziert den Kontext des Autorisierungsservers. Das Feld authentifiziert keinen Nutzer, prüft keinen Code, belegt keine Token-Ausgabe und beweist keine Entscheidung eines Resource Servers.
  • Sicherer Betrieb verbindet getrennte Nachweise für Anfragezustand, erwarteten Issuer, Metadaten, empfangenen Issuer, Vergleich, Code-Einlösung, Token-Prüfung, Ressourcenentscheidung und Wiederherstellung.

Der gefährliche Callback wirkt unauffällig.

Der Browser kehrt zu einer registrierten Redirect URI zurück. state stimmt mit dem vom Client erzeugten Wert überein. Die Antwort trägt einen Code, den ein ehrlicher Autorisierungsserver ausgestellt hat. Weder wurde ein Passwort gestohlen noch der Code gefälscht. Dennoch kann ein Client mit mehreren Autorisierungsservern den entscheidenden Routingfehler begehen: Er schickt den echten Code an einen vom Angreifer kontrollierten Token Endpoint.

Der Fehler entsteht zwischen zwei für sich plausiblen Aufzeichnungen. Die erste sagt, welchen Server der Client beim Start gewählt zu haben glaubte. Die zweite ist eine Autorisierungsantwort, die über den Browser des Nutzers zurückkehrt. Die ursprüngliche OAuth-2.0-Antwort nannte ihren Erzeuger nicht ausdrücklich. Wenn ein generischer Callback oder feindliche Metadaten diese Grenze verwischen, kann ein gültiges Credential in die Kontrolle eines anderen Betreibers wechseln.

RFC 9207 schließt die Lücke mit einem bewusst kleinen Mechanismus. OAuth 2.0 Authorization Server Issuer Identification, im März 2022 als IETF Standards Track veröffentlicht, ist gemeinsame Arbeit von Karsten Meyer zu Selhausen und Daniel Fett. Die Spezifikation definiert iss in der Autorisierungsantwort. Ein unterstützender Server setzt seinen Issuer-Identifier in Erfolgs- und Fehlerantworten. Der Client vergleicht ihn mit dem Issuer des Servers, an den er die Anfrage gesendet hat.

Stimmen die Zeichenketten nicht überein, muss der Client die Antwort ablehnen und darf den Grant nicht fortsetzen.

Das ist die gesamte Autorität des Feldes — und der Grund für seinen Wert.

Dem Callback fehlte der Absender

OAuth trennt Rollen absichtlich. Der Resource Owner verwendet einen User Agent. Ein Client bittet den Autorisierungsserver um einen Grant. Danach legt er den Code beim Token Endpoint vor. Erst der Access Token wird am Resource Server verwendet. Die Zusammensetzung unabhängiger Dienste schafft Routingentscheidungen, die nicht dadurch sicher werden, dass der Browser am erwarteten Callback ankommt.

RFC 6749 gab der Antwort einen Code und, falls in der Anfrage vorhanden, denselben state. Dieser Zustand ist unverzichtbar: Er bindet die Antwort an den authentifizierten Browserzustand und schützt unter anderem vor CSRF. Er beantwortet aber nicht die andere Frage: Welcher Autorisierungsserver hat geantwortet?

Bei genau einem Server kann die Unterscheidung unsichtbar bleiben. Sobald ein zweiter hinzukommt, reicht „ein OAuth-Ablauf ist offen“ als Zustand nicht mehr. Der Client muss wissen, welchem Issuer er gehört. RFC 9700, die aktuelle Best Current Practice für OAuth-Sicherheit, verlangt von Clients mit mehreren Autorisierungsservern einen Schutz gegen Mix-Up und die Bindung des erwarteten Issuers an jede Anfrage.

Daniel Fetts öffentliches Profil erklärt die fachliche Kontinuität, ohne einen gemeinsamen Standard zum persönlichen Mythos zu machen. Seine Website beschreibt ihn als Sicherheitsberater für Identität und Webprotokolle mit Arbeit an OAuth und OpenID Connect. Im September 2026 führte der IETF Datatracker vier RFCs, darunter RFC 9207. Das ist Kontext, kein Beweis für Alleinautorschaft oder Kontrolle über eine Implementierung.

Ein Issuer bezeichnet ein Endpoint-Bündel

Der Issuer-Identifier ist kein Anzeigename. RFC 8414 definiert ihn als HTTPS-URL ohne Query oder Fragment. Er verankert ein Metadatendokument, das Authorization Endpoint, Token Endpoint, Schlüsselorte und weitere Fähigkeiten beschreiben kann. Selbst ein Host kann durch unterschiedliche Pfade mehrere Issuer tragen.

Dieses Bündel ist das Schutzobjekt. Der Nutzer kann eine ehrliche Autorisierungsseite sehen, während der Client sie mit einem Token Endpoint des Angreifers kombiniert. RFC 9700 warnt deshalb, dass die URL des Authorization Endpoints allein nicht genügt: Ein böswilliger Akteur kann die ehrliche URL als seine ausgeben und den eigenen Token Endpoint angeben. Der Issuer ist der stabile Identifier für die gesamte erwartete Zusammenstellung.

RFC 9207 bindet die vom Browser gelieferte Antwort wieder daran. Bei RFC-8414-Metadaten muss iss in der Antwort identisch mit issuer in den Metadaten sein; der Server signalisiert Unterstützung über authorization_response_iss_parameter_supported. Der Client extrahiert und form-dekodiert den Wert und führt einen einfachen Stringvergleich mit dem erwarteten Issuer aus.

Ungefähre Gleichheit gibt es nicht. Ein anderer Pfad, ein zusätzlicher Slash oder zwei Issuer auf demselben Host sind nicht „nahe genug“. Es geht nicht um menschliche Ähnlichkeit, sondern deterministisches Routing.

Die Entscheidung bleibt lokal. Der Server erklärt seine Identität; Metadaten beschreiben das Bündel; der Client speichert Auswahl und Supportzustand, vergleicht und bricht ab. Kein globaler Koordinator führt diesen Schritt aus. Das gemeinsame Feld ersetzt keine Betreiberentscheidung.

Gleichheit erlaubt den nächsten Schritt, nicht das Ergebnis

Am leichtesten wird iss missbraucht, indem man dem Feld zu viel zuschreibt.

Ein passender Issuer authentifiziert nicht den Resource Owner. Der Server kann noch einen Login verlangen oder einen Fehler zurückgeben. Auch eine informierte Zustimmung zum Scope folgt daraus nicht; sie gehört zur Autorisierungsinteraktion und Produktpolitik.

Die Übereinstimmung validiert den Code nicht. Der richtige Token Endpoint muss Code, Client-Identität, Redirect URI und weitere Bedingungen prüfen. Der Code kann abgelaufen, wiederverwendet oder an einen anderen Client gebunden sein.

Ebenso wenig beweist iss eine Token-Ausgabe. Token-Typ, Audience, Scope, Laufzeit, Senderbindung und Widerruf sind eigene Eigenschaften. Der Resource Server entscheidet bei Vorlage. Selbst ein gültiger Token belegt weder eine erfolgreiche Anwendungshandlung noch ein vom Nutzer gesehenes Ergebnis.

Die Beweiskette lautet daher: Anfrage und erwarteter Issuer werden mit dem Browserzustand gespeichert; eine Antwort kommt an; sie nennt einen Issuer; der Client vergleicht und akzeptiert oder verwirft; validierte Metadaten liefern Endpoints; der Token Endpoint akzeptiert oder verwirft den Code; der Resource Server prüft den Token; die Anwendung beobachtet ein Ergebnis und bewahrt Wiederherstellungsdaten.

RFC 9207 besitzt den Vergleich. Wer ihn „OAuth-Erfolg“ nennt, löscht alle späteren Entscheidungen.

Das Feld ist keine Signatur

iss in der normalen Autorisierungsantwort ist nicht kryptografisch geschützt. RFC 9207 sagt das ausdrücklich. Ein Widerspruch entsteht nur, wenn das Feld als universelles Authentizitätszertifikat behandelt wird.

Das Bedrohungsmodell ist enger. Beim Mix-Up erhält der Client eine Antwort eines nicht kompromittierten Servers, verwechselt aber das Endpoint-Bündel für den Code. Kann der Angreifer diese ehrliche Antwort vor dem Client verändern, kann er auch den Code direkt lesen und braucht keinen Mix-Up. Das Feld beseitigt die Routingverwechslung im Modell; es verspricht keine Integrität gegen jeden Angreifer.

Wo Integrität erforderlich ist, können andere Verfahren den Issuer geschützt transportieren. JARM verwendet ein signiertes JWT. Bestimmte OpenID-Connect-Flows liefern ein ID Token vom Authorization Endpoint und können den Issuer enthalten, wenn er korrekt validiert wird. Widersprechen sich mehrere Issuer-Identifier, ist die Antwort abzulehnen.

Das ist Minimum Initial Specification in der Praxis: das kleinste gemeinsame Signal definieren, das die Mehrdeutigkeit sichtbar macht, und stärkere Hüllen, Kompatibilität und Migration lokalen Entscheidungen überlassen. RFC 9700 erlaubt als Alternative getrennte Redirect URIs je Issuer, sofern der Client sie prüft.

Legacy-Kompatibilität braucht einen Eigentümer

Nicht alle Server werden gleichzeitig aktualisiert. RFC 9207 verwaltet deshalb Supportzustand pro Server.

Weiß der Client, dass ein Server iss unterstützt, muss er eine Antwort ohne den Parameter ablehnen. Bei einem nicht unterstützenden Server kann lokale Politik die Antwort zulassen oder die Integration verweigern. Auch ein unerwarteter iss von einem Server ohne Supportanzeige verlangt eine bewusste Entscheidung, weil er Konfigurationsdrift zeigen kann.

Diese Flexibilität lokalisiert Verantwortung. Ein Multi-Issuer-Client braucht Inventar, Metadaten, Endpoints, Supportquelle und -datum, Legacy-Ausnahme, Verantwortlichen und Enddatum. Ohne Ausstieg wird „Kompatibilität“ zum dauerhaften Weg um die Verteidigung.

Auch der zweite Anbieter ist ein Sicherheitszustandswechsel. Was bei einem Issuer nicht nötig war, genügt nach der Erweiterung nicht. Die Anfragebindung muss vor dem Produktstart im laufenden Code stehen.

Der Beleg, den der Betrieb testen kann

Ein einmaliger Metadatenabruf beweist keine Implementierung. Der Test beginnt bei der Anfrage.

Er protokolliert Anfrage-ID, User-Agent-Bindung, ausgewählten Issuer, Metadatenversion, Endpoints, Supportflag und Redirect URI. Bei der Rückkehr erfasst er Vorhandensein und dekodierten Wert von iss, Erwartungswert, Vergleich und die tatsächliche Unterdrückung der Code-Einlösung. Erfolgs- und Fehlerantworten, fehlende und doppelte Werte, unbekannte Issuer und unterschiedliche Pfade auf demselben Host gehören in den Test.

Entscheidend ist der negative Nachweis. Nach einer Abweichung darf keine Anfrage mit Code, Client-Credential oder Token den unerwarteten Endpoint erreichen. Client-Logs und kontrollierte Test-Endpunkte müssen übereinstimmen. Eine sichtbare Fehlermeldung bei dennoch versendeter Netzwerkanfrage ist keine Verteidigung.

In der Incident-Analyse belegt ein Issuer-Mismatch eine fehlgeschlagene Identitätsprüfung, nicht automatisch einen Einbruch. Eine Ablehnung am Token Endpoint beweist nur die Ablehnung dieses Grants. Eine Ressourcenverweigerung beweist rückwirkend keine korrekte Issuer-Bindung.

Das Feld erfüllt seinen Zweck, wenn es eine unsichtbare Mehrdeutigkeit vor der Bewegung eines Geheimnisses zur Pflichtentscheidung macht. Es benennt den Server. Token und Ergebnis benötigen weiterhin ihre eigenen Nachweise.

Quellen