Zusammenfassung

  • Ein Angreifer kann auf seinem Gerät einen legitimen Ablauf starten und dem Opfer den echten Prüfpfad samt Code übermitteln. Nach der Anmeldung beim echten Autorisierungsserver erhält das Angreifergerät die gültige Berechtigung.
  • Vor der Freigabe müssen Initiator, Client, konsumierendes Gerät, Ressource, Umfang, Handlung und Folge gebunden werden. Danach braucht es Nachweise über Token-Nutzung, Widerruf und das Ende jeder abhängigen Sitzung.

Der angebliche Helpdesk bittet eine Mitarbeiterin, einen Fernseher neu zu verbinden. Er nennt einen Code, den sie auf der offiziellen Seite im Diensttelefon eingibt. Die Passkey-Prüfung gelingt, und sie bestätigt. Der Fernseher war nie beteiligt: Der Helpdesk hatte den Code auf einem eigenen Client erzeugt.

Kein Passwort wurde gestohlen. Die Kryptografie hielt. Falsch war die Geschichte, die zwei Geräte miteinander verband.

RFC 10027, seit August 2026 BCP 247, trennt geräteübergreifende Autorisierung vom Sitzungstransfer und beschreibt Angriffe über verschiedene sowie innerhalb desselben Protokolls. Ihr gemeinsames Ziel ist der nicht authentisierte Kontextkanal zwischen dem Consumption Device, das anfordert, und dem Authorization Device, an dem der Mensch entscheidet.

Der Code adressiert einen Vorgang, aber keinen vertrauenswürdigen Ursprung

RFC 8628 ermöglicht Eingabe-beschränkten Geräten, Device Code und User Code abzurufen, einen Prüfpfad anzuzeigen und das Ergebnis der Autorisierung auf einem zweiten Gerät abzufragen. Das löst ein Bedienproblem, macht die menschlich übertragene Referenz aber beweglich.

Kurze Gültigkeit, Einmaligkeit und Eindeutigkeit reduzieren Raten und Wiederholung. Ein interaktiver Angreifer kann erst überzeugen, dann einen frischen Code erzeugen und die erste Zustimmung sofort nutzen. Wiederholungsschutz beweist deshalb nicht, dass der Nutzer den Vorgang begonnen hat.

OAuth 2.0 verteilt Rollen auf Client, Resource Owner, Autorisierungs- und Ressourcenserver. PKCE bindet den Code-Austausch an den Client mit dem ursprünglichen Verifier. Ist das der Angreifer-Client, schützt PKCE die technische Bindung zum falschen Empfänger.

Starke Authentisierung trägt keine Transaktionsbedeutung

WebAuthn Level 3 kann Herkunftsbindung und Phishing-Resistenz bieten. Es belegt, wer beim echten Dienst geantwortet hat. Es belegt nicht automatisch, welches entfernte Gerät, welche Ressource, welcher Scope oder welche irreversible Folge die Person vor Augen hatte.

RFC 10027 empfiehlt den Device Grant nur, wenn Gerätebeschränkungen stärkere Alternativen ausschließen, und rät bei sensiblen, hochwertigen oder geschäftskritischen Ressourcen davon ab. Vorregistrierte Consumption Devices und „erst authentisieren, dann initiieren“ verhindern beliebige Anforderer, sofern Produkt und Hardware dies tragen.

Nähe erhöht Aufwand, ist aber keine Identität. Mobilfunk und WLAN können nahe Geräte fern erscheinen lassen; VPN, Weiterleitung und Standortfälschung können Entfernung verbergen. Präzise Erhebung kostet Datenschutz. Auch ein zweiter Kanal hilft nur, wenn die angezeigten Tatsachen fest an dieselbe Request-ID gebunden und nicht selbst weiterleitbar sind.

Senderbindung schützt ein Token, nicht die Entscheidung

DPoP bindet Zugriffstoken an einen Client-Schlüssel und erschwert Kopien. Kontrolliert der Angreifer das autorisierte Gerät samt Schlüssel, bewahrt DPoP gerade dessen versehentlich gewährte Autorität. RFC 9700 stärkt OAuth 2.0, kann aber fehlende menschliche Absicht nicht nachträglich erzeugen.

OpenID CIBA vermeidet den sichtbaren Code-Transfer und verringert diese Angriffsfläche. Kennt ein Anforderer die Benutzerkennung, bleiben massenhafte Anfragen, Zustimmungs-Ermüdung und falscher Support möglich.

Zur Reaktion gehören Introspektion, Widerruf und CAEP-Ereignisse. Eine erfolgreiche Widerrufsantwort oder ein gesendetes Ereignis beweist nicht, dass Ressourcenserver ihre Caches verworfen und abgeleitete Sitzungen beendet haben.

Ein Kontextjournal statt eines grünen Gesamtstatus

Zu speichern sind Request-ID und Startzeit, Initiator, Client-ID und Version, Identität und Vertrauenszustand des Consumption Device, Authorization Device und Methode, Hash und Laufzeit des Codes, Übertragungskanal, Näherungssignale sowie die genaue Anzeige von Anforderer, Gerät, Ressource, Scope, Handlung, Ziel und irreversibler Folge.

Nach der Zustimmung werden Token-Familie und Bestätigungsschlüssel mit der Nutzung an jedem Ressourcenserver verbunden. Ablehnung, Anomalie, Introspektion, Widerruf, CAEP-Zustellung und bestätigtes Sitzungsende bleiben getrennte Zustände.

Heng Lus Vorrang laufenden Codes legt die operative Wahrheit beim Client und Ressourcenserver ab, die Zugriff tatsächlich ausüben. Seine minimale Anfangsspezifikation mit lokalen Folgeentscheidungen erlaubt einen schmalen gemeinsamen Evidenzvertrag bei lokaler Wahl von Nähe oder Gerätevertrauen. Die Trennung von formaler und praktischer Kontrolle erklärt das Ergebnis: Der Server gewährt formale Rechte; Schlüssel und lebende Sitzung verleihen praktische Macht.

Das Smartphone kann die Person bestätigen. Die Organisation muss zusätzlich den Anforderer bestätigen.