Zusammenfassung

  • Justin Richers individueller Internet-Draft vom 28. September beschreibt eine einzige kopierbare Zeichenfolge für den Weg vom Browser zu einem entfernten OAuth-Client.
  • Die HKDF/XOR-Kombination schafft keinen zusätzlichen Sicherheitsnachweis: Die Hilfsseite empfängt code und state, und der Client muss die laufende Anfrage selbst zuordnen.

Eine Kommandozeile auf einem entfernten Rechner kann die Autorisierung anstoßen, aber keinen für den Browser erreichbaren Rückleitungsendpunkt bereitstellen. draft-richer-oauth-oob-authcode-00 setzt an dessen Stelle eine registrierte Hilfsseite. Der Nutzer entnimmt ihr eine Zeichenfolge und fügt sie in den wartenden Client ein. Der am 28. September 2026 eingereichte Text ist ein individueller Internet-Draft mit informativem Ziel. Im Datatracker steht I-D Exists; weder eine Arbeitsgruppe noch die IETF hat ihn damit als Standard verabschiedet, und ein RFC ist er nicht.

Der Autorisierungsserver leitet die gewohnte Antwort an die registrierte URI. Die Seite verarbeitet code und state mit aus state abgeleitetem HKDF-Material, XOR und einer Prüfsumme zu einem Wert. Der Client besitzt sein ursprüngliches state, gewinnt den Code zurück und führt den normalen Schritt am Token-Endpunkt aus. Ein neuer Grant ist nicht vorgesehen. Aus Sicht eines Serverbetreibers ist vor allem die Registrierung der Hilfs-URI nötig, nicht die Implementierung einer zusätzlichen Serverfunktion.

Diese Ersparnis hat eine sichtbare Gegenbuchung. Der Entwurf selbst verneint einen Sicherheitsgewinn gegenüber dem einfachen Autorisierungscode-Verfahren. code und state erreichen die Hilfsseite zunächst als Parameter einer GET-URL. Auch bei einer rein statischen Seite können Hosting-Anbieter, CDN, Spiegel, Cache und Zugriffsprotokolle die Parameter sehen. Die spätere Darstellung als eine Zeichenfolge macht die vorangegangene Rückleitung nicht unsichtbar.

Die Zeichenfolge beglaubigt auch keinen Aussteller. Die Berechnung lässt sich mit beliebigen Werten wiederholen. Der Client muss sie daher mit seiner noch offenen Anfrage, dem gespeicherten state und dem vorgesehenen Server sowie Token-Endpunkt verbinden. Ein zustandsloser Client ohne behaltenes state kann dieses Verfahren nicht verwenden. Scheitert JavaScript, nennt der Text als Ausweichweg das Kopieren der ganzen URL. Das ist eine Übergabe der ursprünglichen Parameter und nicht dieselbe kombinierte Darstellung.

Im Standardfall gehen außerdem nicht sämtliche Antwortfelder mit. Die Kombination enthält code und state, aber iss nicht als eigenständigen Parameter. Abschnitt 3.4 erwägt eine Verwendung von iss als HKDF-INFO, sofern der Client dessen Vorhandensein kennt. RFC 9207 regelt bereits die Identifikation des Autorisierungsservers gegen Verwechslungen bei Clients mit mehreren Servern. Daraus folgt kein pauschaler Angriff auf jede Umsetzung dieses Entwurfs. Für einen Mehrserver-Client muss jedoch klar sein, wie seine bestehende Ausstellerbindung die manuelle Übergabe übersteht.

Die Geräteautorisierung aus RFC 8628 bleibt ein anderer Weg, der Serverunterstützung und Polling braucht. Der neue Entwurf hebt sie nicht auf. Er bietet eine Alternative für Clients, die den Autorisierungscode-Fluss wiederverwenden möchten. Ob eine solche Migration sinnvoll ist, hängt nicht nur vom Aufwand im Server ab, sondern auch von der Beherrschbarkeit der Hilfsseite und ihrer Protokolle.

Quellen