Zusammenfassung

  • RFC 10017 ordnet drei Muster nach abnehmender Sicherheit: vollständiges BFF, Token-vermittelndes Backend und OAuth-Client im Browser.
  • Das BFF hält Access Token, Refresh Token und vertrauliche Client-Zugangsdaten vom JavaScript fern, doch schädlicher Code in der erlaubten Origin kann weiterhin über die Cookie-Session Befehle an das BFF senden.
  • Verantwortliche müssen Origin und Code-Lieferkette, Cookies und CSRF, BFF-Ziel/Path/Methode, Resource-Autorisierung, Bestätigung irreversibler Aktionen, Session-Widerruf und den tatsächlichen Commit getrennt nachweisen.

Ein Beschaffungsportal genehmigt eine neue Lieferantenverbindung. Die Architektur gilt als vorbildlich: kein OAuth-Token in Browser-Speichern oder Frontend-Logs, ein HttpOnly-Cookie für die Session, ein BFF mit Server-Vault für Access und Refresh Token.

Ein kompromittiertes Analyse-Skript sendet im Hintergrund einen zweiten Auftrag. Der Browser fügt den Cookie an. Das BFF erkennt die Session, holt das Token und ruft die Lieferanten-API auf. Issuer, Audience und Scope passen; die Änderung wird gespeichert. Das Token blieb unangetastet. Der Befehl nicht.

RFC 10017, im August 2026 als IETF Best Current Practice veröffentlicht, macht diesen Restbereich sichtbar. Das BFF beseitigt mehrere mächtige Angriffe. Es erklärt Code in der korrekten Origin jedoch nicht zum rechtmäßigen Vertreter des Nutzers.

Nach der Code-Ausführung besitzt der Angreifer vier Wege

Das Bedrohungsmodell setzt ein, wenn schädliches JavaScript oder WebAssembly bereits im Anwendungskontext läuft. Dieser Code teilt die Browser-Rechte der legitimen Anwendung. Er kann erreichbare Daten und Same-Origin-Kontexte nutzen, Abläufe verändern und Requests aus der erlaubten Origin erzeugen.

RFC 10017 unterscheidet vier Szenarien. Ein einmaliger Diebstahl kopiert die vorhandenen Token. Ein persistenter Diebstahl nimmt jede neue Version. Ein drittes Verfahren ignoriert gespeicherte Token und startet einen frischen Authorization Code Flow unter Nutzung der bestehenden Authorization-Server-Session. Das vierte Verfahren exportiert gar nichts, sondern lässt den Browser selbst den Request ausführen.

Damit bekommt jede Abwehr eine präzise Reichweite. Kurze Access-Token-Laufzeiten verkleinern die Nutzungsdauer einer Kopie, nicht die Beobachtungsdauer von persistentem Code. Refresh Token Rotation kann Wiederverwendung erkennen; ein Angreifer kann aber stets die neueste Version nehmen und die legitime Verwendung unterdrücken. Isolierter Storage schützt den vorhandenen Wert, nicht zwingend den Weg zu einem neuen.

PKCE verhindert, dass ein abgefangener Authorization Code von einer anderen Instanz eingelöst wird. Es unterscheidet nicht die Absicht zweier Programme innerhalb derselben registrierten Redirect-Origin. DPoP und nicht exportierbare Schlüssel begrenzen den Off-Device-Einsatz einer Token-Kopie. Sie verhindern nicht zwingend, dass schädlicher Same-Origin-Code einen neuen Flow mit eigenem Schlüssel beginnt oder eine aktive Signaturfunktion benutzt.

Das BFF schließt drei Pfade und übernimmt den vierten

Beim vollständigen BFF ist die Serverkomponente der vertrauliche OAuth-Client. Sie führt Authorization Code mit PKCE aus, verwahrt Access und Refresh Token, ordnet sie einer Cookie-Session zu und proxyt jeden Aufruf zum Resource Server. Das Frontend erhält kein OAuth-Token.

Drei Vorteile sind eindeutig. Im Browser liegt kein Token für einmaligen oder fortlaufenden Diebstahl. Selbst mit einem Authorization Code kann schädlicher Browser-Code ohne BFF-Zugangsdaten nicht als registrierter vertraulicher Client tauschen. HttpOnly verhindert außerdem das direkte Lesen der Session-ID und erschwert die Verwandlung von Client-Hijacking in eine portable Session.

Übrig bleibt der In-Context-Befehl. Die Anwendung muss das BFF aufrufen können. Schädlicher Code in derselben Origin kann denselben Endpoint benutzen; der Browser sendet den Cookie, das BFF übersetzt die Session in einen tokenbewehrten Upstream-Request. Der Angreifer umgeht nicht den Token-Vault, sondern nutzt die vorgesehene Befehlsbahn.

Deshalb darf ein BFF kein allgemeines Weiterleitungswerkzeug sein. RFC 10017 verlangt strikte Ausgangskontrollen: festgelegte Hosts und Paths, bei Bedarf eingeschränkte HTTP-Methoden. Ein Browser-Parameter darf nicht frei bestimmen, wohin das BFF das Token sendet. Sonst wird gute Geheimnisverwahrung zur offenen Proxy-Befugnis.

Auch Cookies haben einen eigenen Vertrag. Secure und HttpOnly sind Pflicht; SameSite=Strict, Path /, kein Domain-Attribut und ein hostgebundener Prefix werden empfohlen. Zustandsändernde Routen benötigen trotzdem CSRF-Abwehr, weil der Browser den Cookie anhängen kann, ohne ihn JavaScript zu zeigen.

Das BFF bündelt Client-Credentials, Token, Session und Routing. Dadurch kann es Anomalien und Raten über den gesamten Pfad erkennen. Gleichzeitig entsteht eine zentrale Abhängigkeit für Kapazität, regionalen Session-Status, Widerruf und Recovery.

Token-Vermittlung schützt die Erneuerung, nicht jeden Zugriff

Das Token-vermittelnde Backend bleibt vertraulicher Client und hält den Refresh Token im Server. Es gibt jedoch Access Token an den Browser aus, der Resource Server direkt aufruft. Das reduziert Proxy-Kosten und legt genau jene kurzfristige Autorität wieder offen.

Schädlicher Code kann keinen Refresh Token stehlen und den vertraulichen Flow nicht allein abschließen. Er kann den Access Token kopieren. Selbst wenn isolierter Speicher dessen Lesen erschwert, kann der Code über die gültige Session beim Vermittler einen aktuellen Token anfordern.

Auch DPoP-Verantwortung wird geteilt: Der Server beschafft den Token, der Browser benutzt ihn. RFC 10017 definiert dieses Split-Modell nicht. Ein Architekturpfeil mit „PoP“ beweist weder Schlüsselverwahrung noch Proof-Erzeugung. Das Dokument empfiehlt daher, zuerst ein vollständiges BFF zu prüfen und Vermittlung nur bei einem konkreten, dokumentierten Hindernis einzusetzen.

Ein Browser-Client bleibt öffentlich

Übernimmt JavaScript alle OAuth-Aufgaben, ist ein eingebettetes Shared Secret nicht geheim und kein Nachweis eines vertraulichen Clients. Authorization Code mit PKCE, exakt registrierte Redirect URIs und CSRF-Schutz sind zwingend. Werden Refresh Token ausgegeben, muss der Authorization Server sie rotieren oder sender-binden und eine maximale oder inaktivitätsbedingte Laufzeit festlegen.

Diese Regeln beseitigen die vier Angriffe nach einer Origin-Kompromittierung nicht. Die Origin aus Scheme, Host und Port ist eine reale Befugnisgrenze. RFC 10017 empfiehlt eine Anwendung pro Origin. Organisatorisch getrennte Produkte unter derselben Origin teilen Browser-Möglichkeiten, die ihre Teams möglicherweise getrennt bewertet haben.

CORS steuert, ob eine Cross-Origin-Response dem Browser-Code zugänglich wird. Es ist keine Resource-Autorisierung und unterscheidet innerhalb einer erlaubten Origin nicht zwischen legitimem und schädlichem Code. Bei postMessage müssen Sender- und Empfänger-Origin exakt geprüft werden.

Ein Service Worker steht nicht über der Origin

Ein Service Worker kann Token in isoliertem Speicher halten und Requests anreichern. Er wirkt wie ein lokales BFF. RFC 10017 empfiehlt dieses OAuth-Flow-Muster nicht: Schädlicher Anwendungscode kann den Worker deregistrieren und einen neuen Browsing Context ohne dessen Kontrolle öffnen, um einen weiteren Flow zu starten.

Die Isolation schützt existierende Token, schafft aber keine unabsetzbare Autorität. Ähnlich garantiert ein nicht exportierbarer Web-Crypto-Schlüssel nur die API-Eigenschaft; nicht zwingend TPM-Schutz oder verschlüsselten Dateispeicher. Falscher Code kann eine richtige Umgebung möglicherweise weiterhin zum Einsatz des Schlüssels veranlassen.

Beweise müssen bis zum Geschäftsergebnis reichen

Eine belastbare Kette verbindet Frontend-Version, Origin, Abhängigkeiten und CSP, einen datensparsamen Session-Hash, CSRF-Ergebnis, BFF-Route, Upstream-Host/Path/Methode, Token-Audience und Scopes, Resource-Policy, Objektzustand, Idempotency Key und Commit-Ergebnis. Roh-Token, Cookies und Client Secrets gehören nicht ins Log.

Negative Tests trennen Fähigkeiten: vorhandenen Token lesen, Rotation verfolgen, neuen Flow starten, Token beim Vermittler anfordern, BFF ohne Token-Sicht benutzen, Ziel verändern und irreversible Aktion nach verlorener Antwort wiederholen. Ein einziges „OAuth gültig“ kann diese Zuständigkeiten nicht erklären.

Running-Code Primacy verlangt den Nachweis in den laufenden Komponenten. „BFF“ ist ein Etikett; Cookie-Regeln, Route-Mappings, Vault, Resource-Entscheidungen und Fehlerverhalten sind Realität. Minimum Initial Specification hält die gemeinsamen OAuth-Regeln deterministisch, während der verantwortliche Service die Wirkung autorisiert. Ein sicher verwahrtes Token ist keine Vollmacht für jeden Befehl.