Summary

  • draft-richer-oauth-oob-authcode-00 verpackt Authorization Code und clientseitig gespeicherten state in einen kopierbaren Wert; es ist ein individueller Internet-Draft, kein angenommener OAuth-Entwurf und kein RFC.
  • Eine statische Hilfsseite nutzt HKDF, XOR und eine Drei-Byte-Prüfsumme. Der Client rekonstruiert den Code und muss ihn weiterhin am Token Endpoint eintauschen.
  • Eine passende Prüfsumme belegt nur eine konsistente Rekonstruktion, nicht Vertraulichkeit, Issuer, PKCE, Token-Ausgabe, Resource-Berechtigung oder Geschäftsergebnis.

Ein Mensch ersetzt den Rückruf

Revision 00 registriert eine statische Hilfsseite als redirect_uri. Der Authorization Server leitet den Browser mit code und state dorthin. Die Seite zeigt einen kombinierten Wert, den der Nutzer in den wartenden Client kopiert.

Die Seite hat keinen Backend-Zustand, kein gemeinsames Geheimnis und fordert kein Token an. Der AS muss das Verfahren nicht kennen. Es verkleinert allein die fehleranfällige manuelle Übergabe.

Anzeigen, Kopieren, Rekonstruieren und Eintauschen bleiben getrennte Ereignisse.

Drei Bytes sind keine Absenderbestätigung

Der Code wird C. HKDF erzeugt aus UTF-8-state, leerem Salt und gemeinsamem INFO ein gleich langes KS; danach gilt E = C XOR KS. Die ersten drei Bytes von SHA256(C) bilden T. T und E werden getrennt ohne Padding base64url-kodiert und zu CC verbunden.

Der Client leitet KS aus seinem gespeicherten state erneut ab, gewinnt C zurück und vergleicht T. Bei Abweichung scheitert er; Eingaben bis zur vier Zeichen langen Prüfsumme werden verworfen. Erst danach geht der Code an den Token Endpoint.

T ist kein MAC des Authorization Servers. Jeder kann die öffentliche Seite mit beliebigen Werten nutzen. Eine Übereinstimmung benennt weder Ersteller noch Browsersitzung und verspricht keine spätere Annahme.

Die Infrastruktur sieht die Werte zuerst

Code und state stehen im GET der Hilfsseite. Origin, CDN, Spiegel und Caches können beide empfangen. HKDF läuft erst danach. Der Entwurf erklärt ausdrücklich, dass die Kryptofunktionen keinen zusätzlichen Schutz schaffen und den Code nicht geheim halten.

Wer beide Werte stiehlt, wird durch CC nicht aufgehalten. Ein zustandsloser Client kann nichts dekodieren. Ohne JavaScript soll die ganze URL kopiert werden; dieser Fallback nutzt kein HKDF.

Andere Parameter wie iss fallen weg. Nur wenn der Client weiß, dass der AS iss liefert, könnte es Teil von INFO sein. Issuer-Prüfung bleibt also ein eigenes Receipt.

Der normale OAuth-Teil bleibt

RFC 6749 regelt weiter Bindung, Redirect, Lebensdauer und Token Request. PKCE verlangt weiterhin den passenden verifier. Client-Authentisierung, Einmalgebrauch und RFC 9700 werden nicht von der Prüfsumme übernommen.

RFC 8628 bietet mit Device Code und Polling eine servergestützte Alternative. Weniger Serveranpassung und Round Trips sind ein Betriebsargument, aber kein Gleichheitsbeweis für Sicherheit oder Recovery.

Lu Hengs Minimum Initial Specification hält die gemeinsame Funktion klein: weniger Übertragungsfehler. Running-Code Primacy prüft anschließend, was Client, Token Endpoint und Resource Server wirklich akzeptierten. Eine Zeichenfolge macht daraus keine einzige Realität.

Quellen und Grenzen

Die Quellen belegen keine OAuth-Annahme, keinen IETF-Konsens, RFC, Implementierung, Interoperabilität, Deployment, fertigen Login, Token-Ausgabe, Angriff, Abwehrerfolg oder Resource-Ergebnis. Der bestehende RFC-10027-Artikel behält das Angreifer-Device-Kontextproblem; hier geht es nur um das Rekonstruktions-Receipt des ehrlichen Revision-00-Ablaufs.