Zusammenfassung

  • DPoP nimmt einem Bearer-Token eine Eigenschaft: Der Tokenwert allein genügt nicht mehr. Der Absender muss für jeden Request einen neuen Nachweis mit dem privaten Schlüssel erzeugen, dessen öffentlicher Fingerabdruck an das Token gebunden ist.
  • Der Nachweis bindet Methode, Ziel-URI ohne Query und Fragment, Erstellungszeit, eindeutige Kennung, Token-Hash und gegebenenfalls eine Server-Nonce. Er signiert weder den gesamten Request noch erteilt er die fachliche Erlaubnis.
  • Der Resource Server muss weiterhin Aussteller, Audience, Laufzeit, Status und Privilegien des Tokens prüfen, Replay-Zustand koordinieren, die richtige externe URI rekonstruieren und Subjekt, Client, Ressource, Handlung sowie aktuellen Objektzustand autorisieren.

Ein gestohlenes Token, das nicht mehr genügt

In einem Diagnosepaket landet versehentlich ein OAuth Access Token. In einem Bearer-System ist die Zeichenfolge selbst das Zugangsmerkmal. Wer sie besitzt und einen akzeptierenden Resource Server erreicht, kann die vom Token dargestellte Befugnis bis zum Ablauf oder Widerruf nutzen.

Das geleakte Token ist jedoch DPoP-gebunden. Ein Angreifer kopiert es in einen anderen Client und sendet einen Request. Der Resource Server erwartet das Token unter dem DPoP-Schema und zusätzlich einen signierten DPoP-Nachweis. Dem Angreifer fehlt der private Schlüssel zum gespeicherten Public-Key-Thumbprint. Eine Proof mit einem eigenen Schlüssel passt nicht; eine alte, mitgeschnittene Proof scheitert an Methode, URI, Zeit, Nonce oder Replay-Prüfung.

Das ist ein echter Gewinn. Wer nur den Tokenwert exfiltriert, besitzt außerhalb der Signierumgebung kein vollständiges Zugangsmerkmal mehr.

Nun stellt der legitime Client denselben Request. Die Signatur stimmt, htm und htu passen, ath stimmt mit dem Token überein, die Proof ist frisch und jti unbekannt. Trotzdem verweigert der Server die Handlung. Das Token kann für eine andere Audience bestimmt sein, nur Leserechte enthalten, zu einem inzwischen gesperrten Konto gehören oder eine Ressource betreffen, die bereits einen unveränderlichen Zustand erreicht hat.

DPoP hat dabei nicht versagt. Die Senderbindung beantwortete, ob der gebundene Schlüssel für diesen Request benutzt wurde. Die Autorisierung beantwortete, ob dieser Kontext diese Folge jetzt auslösen darf. Beide Antworten müssen getrennt sichtbar bleiben.

Vom Besitz eines Wertes zur Schlüsselbenutzung

RFC 6750 definiert die Bearer-Eigenschaft: Wer ein Token besitzt, kann es ohne kryptografischen Besitznachweis benutzen. TLS, sichere Ablage, kurze Laufzeiten und Audience-Beschränkung senken Wahrscheinlichkeit und Ausmaß eines Leaks, beseitigen aber nicht die Portabilität des kopierten Wertes innerhalb seiner Akzeptanzfläche.

RFC 9449 ergänzt einen Nachweis auf Anwendungsebene. Der Client wählt ein asymmetrisches Schlüsselpaar und sendet am Token Endpoint eine signierte DPoP Proof. Der Authorization Server kann das ausgegebene Access oder Refresh Token an den JWK Thumbprint des öffentlichen Schlüssels binden. Am geschützten Ziel präsentiert der Client Token und neu signierte Proof; der Resource Server prüft, ob der Proof-Schlüssel dem Token-Schlüssel entspricht.

RFC 9700 empfiehlt Senderbindung, Audience-Beschränkung und Least Privilege als getrennte Maßnahmen. Genau diese Trennung verhindert semantische Überdehnung. Eine Schlüsselbindung repariert kein Token für den falschen Dienst, macht aus read kein write, erzeugt keine Einwilligung und konserviert keine Berechtigung, die sich seit der Ausstellung geändert hat.

Ein JWK Thumbprint ist ein deterministischer SHA-256-Wert aus den normierten Pflichtfeldern des öffentlichen Schlüssels. Er identifiziert Schlüsselmaterial, nicht automatisch Mensch, Unternehmen, Gerätezustand, Absicht oder Mandat. Kryptografische Eindeutigkeit ist keine Erlaubnis, einen technischen Bezeichner zur Identität aufzuwerten.

Was die Proof tatsächlich enthält

Eine DPoP Proof ist ein als JWS signiertes JWT. Der geschützte Header führt ausdrücklich typ: dpop+jwt, einen lokal zulässigen asymmetrischen alg und die öffentliche jwk ohne privates Material. Dadurch kann der Empfänger ein DPoP-spezifisches Prüfprofil wählen, statt jedes signierte JWT in einen allgemeinen „gültig“-Pfad zu leiten. RFC 8725 liefert die übergeordnete Regel: Typ, Algorithmus, Issuer, Audience und Prüfregeln sind Entscheidungen der Anwendung.

Der Payload enthält htm für die HTTP-Methode, htu für die Ziel-URI ohne Query und Fragment, iat für den Erstellungszeitpunkt und jti als mit vernachlässigbarer Kollisionswahrscheinlichkeit erzeugte Proof-Kennung.

Bei einem Resource Request kommt ath hinzu, der SHA-256-Hash des exakt präsentierten Access-Token-Wertes. Der Empfänger berechnet ihn neu. Eine Proof, die zusammen mit einem Token abgefangen wurde, kann dadurch nicht mit einem anderen Token kombiniert werden, auch nicht unter demselben Proof Key.

Hat der Server mit DPoP-Nonce herausgefordert, führt die nächste Proof diese Nonce. Ein aktueller, unvorhersehbarer Wert entwertet vorproduzierte Stapel signierter Nachweise und zeigt, dass die Signierfähigkeit auf eine kürzlich vom Server gewählte Vorgabe reagiert hat.

Keines dieser Felder vollzieht seine Prüfung selbst. Der Empfänger muss doppelte DPoP-Felder, fehlerhafte JWTs, fehlende Claims, falsche Typen, unzulässige Algorithmen, ungültige Signaturen und private JWK-Anteile ablehnen. Danach vergleicht er Methode und URI, erzwingt das Zeitfenster, berechnet ath, gleicht den gebundenen Thumbprint ab und setzt seine eigene Nonce-Regel durch.

Drei Bindungen mit drei verschiedenen Aufgaben

Erstens bindet der Authorization Server das Token an den Schlüssel. Der JWK Thumbprint liegt typischerweise als cnf.jkt am Token. Der Resource Server muss ihn mit dem Thumbprint des öffentlichen Schlüssels vergleichen, der die aktuelle Proof verifiziert.

Zweitens bindet ath die Proof an den exakten Tokenwert dieses Requests. Das verhindert Tokenaustausch, prüft aber weder Audience und Scope noch Gültigkeit oder Widerruf.

Drittens kann die Bindung vor der Tokenausgabe beginnen. Der optionale Authorization-Request-Parameter dpop_jkt bindet den Authorization Code an den vorgesehenen Proof Key. Ohne ihn könnte ein Angreifer, der Code und übriges Einlösematerial erlangt, den Code mit einem eigenen Schlüssel einlösen und ein technisch korrekt DPoP-gebundenes Token erhalten — gebunden an den falschen Sender. Das ergänzt PKCE, Client Authentication und Resource-Owner-Autorisierung; es ersetzt sie nicht.

Eine Implementierung kann eine Bindung richtig umsetzen und eine andere auslassen. Ein einzelnes Feld „PoP aktiv“ reicht daher weder für Audit noch Incident Response. Erforderlich sind Phase, Vergleichswerte und Ergebnis.

Der gebundene Request ist kleiner als der Geschäftsauftrag

htm verhindert, dass eine für GET erzeugte Proof als DELETE verwendet wird. htu bindet sie an ein Ziel. Die Definition dieser Zielbindung ist jedoch bewusst begrenzt: Query und Fragment gehören nicht zu htu. Request Bodies und beliebige Header werden vom Basisverfahren ebenfalls nicht signiert.

Wenn POST /transfer?account=A und POST /transfer?account=B unter der Spezifikation dasselbe htu haben, bindet die Proof das Konto nicht. Ändert sich in JSON Betrag oder Empfänger, entsteht dadurch keine Body-Signatur.

Das ist kein versteckter Mangel, sondern Aufgabenverteilung. DPoP ist Senderbindung, kein Ersatz für HTTP Message Signatures, Transaktionsautorisierung oder fachliche Idempotenz. RFC 9110 beschreibt HTTP-Semantik; die Anwendung verantwortet die Bedeutung von Query, Body und Objektzustand und muss die tatsächliche Wirkung autorisieren.

Proxies verschärfen die Frage. Der Client beweist externes Scheme, Authority und Path. Ein Gateway beendet TLS, schreibt den Pfad um und leitet einen internen Host weiter. Rekonstruiert das Backend htu von der falschen Seite, fallen korrekte Clients aus; akzeptiert es großzügige Alternativen, wächst die Replay-Fläche. Externer Request Context, vertrauenswürdige Forwarding Chain und Normalisierung benötigen einen benannten Eigentümer.

Frische ist verteilter Zustand, keine Syntax

iat und jti ermöglichen Replay-Erkennung, lehnen aber nichts von selbst ab. Der Empfänger legt zulässiges Alter, Clock Skew, Replay Key, Aufbewahrungsdauer und die Topologie fest, in der Seen-State geteilt wird.

Speichert eine Region jti, bevor der Eintrag eine zweite Region erreicht, kann dieselbe Proof dort noch passieren. Sind Check und Write nicht atomar, können zwei parallele Requests beide „unbenutzt“ sehen. Ist die Nonce statisch, zu lange gültig oder zu breit geteilt, sinkt sie vom Gegenwartsnachweis zum Ritual.

Nonces von Authorization Server und Resource Server sind nicht austauschbar. Ein Client mit mehreren Issuern muss sie nach Herausgeber trennen; andernfalls produziert das Frischefeld grenzüberschreitende Fehlermeldungen.

Auch eine abgelehnte Proof-Wiederholung garantiert kein Exactly Once. Ein Client kann zwei frische Proofs für zwei Retries erzeugen. Beide sind kryptografisch einzigartig. Ob nach verlorener Antwort eine Zahlung erneut erfolgt, entscheiden Business Idempotency, Commit Record und Reconciliation — nicht der DPoP Replay Store.

Schlüsselbesitz ist weder Identität noch Zustimmung

Die öffentliche JWK zeigt, welcher Schlüssel eine Signatur bestätigt. Sie sagt nicht, wer ihn erzeugt hat, wer den Prozess kontrolliert, ob er zu einem registrierten Client gehört oder ob ein Nutzer diese Handlung billigt. Confidential Client Authentication kann neben DPoP stehen. Das Token trägt den vom Issuer bestimmten Authorization Context, die Proof trägt Senderbindung, der Resource Service trifft die letzte Entscheidung.

Im Browser ist die Grenze besonders wichtig. RFC 10017 erläutert, wie ein nicht exportierbarer Schlüssel verhindert, dass Token und Key Material für spätere Nutzung in eine andere Umgebung kopiert werden. Bösartiger Code, der bereits unter der Origin der Anwendung läuft, kann jedoch zugängliche Signierfunktionen aufrufen, Requests in der laufenden Session senden oder einen neuen Authorization Flow beginnen. Nicht exportierbar heißt nicht: vom falschen Code nicht benutzbar.

Erlangt ein Angreifer Token und privaten Schlüssel oder dauerhafte Kontrolle über die Signierschnittstelle, verliert die Senderbindung ihre Wirkung. Hardware-Backed Keys verbessern Verwahrung; sie verwandeln einen kompromittierten Client nicht in einen vertrauenswürdigen Principal.

Laufende Evidenz vom Issuer bis zum Commit

IANA registriert DPoP und DPoP-Nonce als permanente HTTP Fields sowie die zugehörigen OAuth Parameters. Gemeinsame Namen ermöglichen Interoperabilität, beweisen aber nicht, dass eine konkrete Produktion dieselbe URI vergleicht, Replay koordiniert und Ressourcenautorisierung erhält.

Die Evidenzkette sollte Proof und Folge verbinden, ohne Raw Token oder Private Keys zu protokollieren: datenschutzgerechter Proof-Hash, Thumbprint, Token Type, ath-Ergebnis, normalisierte externe und interne URI, Proof Age, Nonce Issuer, Replay-Store-Ergebnis, Token Issuer und Audience, Scope-Entscheidung, Resource-Policy-Version und finaler Commit Identifier.

Negative Tests müssen Komponenten überschreiten: kopiertes Token ohne Schlüssel; richtiger Schlüssel mit falschem Token; alte Proof; doppeltes jti; falsche Methode; extern-interner Rewrite; fehlende oder fremde Nonce; falsche Audience; zu wenig Scope; gesperrtes Subjekt; bereits vollzogene Einmaloperation. Jede Ablehnung erklären zu können ist stärker als ein grünes DPoP-Siegel.