Zum Hauptinhalt springen

1. Introduction (Einführung)

1. Introduction (Einführung)

Demonstrating Proof of Possession (DPoP) ist ein Mechanismus auf Anwendungsebene zur Senderbindung (Sender-Constraining) von OAuth [RFC6749] Zugriffs- und Refresh-Token. Es ermöglicht Clients, den Besitz eines öffentlichen/privaten Schlüsselpaares nachzuweisen, indem sie einen DPoP-Header in eine HTTP-Anforderung aufnehmen. Der Wert des Headers ist ein JSON Web Token (JWT) [RFC7519], das es dem Autorisierungsserver ermöglicht, ausgestellte Token an den öffentlichen Teil des Schlüsselpaares des Clients zu binden. Empfänger solcher Token sind dann in der Lage, die Bindung des Tokens an das Schlüsselpaar zu überprüfen, dessen Besitz der Client über den DPoP-Header nachgewiesen hat, und erhalten so die Gewissheit, dass der Client, der das Token vorlegt, auch den privaten Schlüssel besitzt. Mit anderen Worten, der legitime Inhaber des Tokens ist an den Absender gebunden, der den Besitz des privaten Teils des Schlüsselpaares besitzt und nachweist.

Der hier spezifizierte Mechanismus kann verwendet werden, wenn andere Methoden zur Senderbindung von Token, die Elemente der zugrunde liegenden sicheren Transportschicht verwenden (wie [RFC8705] oder [TOKEN-BINDING]), nicht verfügbar oder nicht wünschenswert sind. Beispielsweise kann keine dieser Methoden verwendet werden, wenn der OAuth-Client eine Anwendung ist, die dynamisch heruntergeladen und in einem Webbrowser ausgeführt wird (manchmal auch als "Single Page Application" bezeichnet), da die Benutzererfahrung für TLS-Client-Authentifizierung in User Agents schlecht ist und die Unterstützung für HTTP Token Binding fehlt. Darüber hinaus sind Anwendungen, die direkt auf einem Benutzergerät installiert und ausgeführt werden, gut positioniert, um von DPoP-gebundenen Token zu profitieren, um die missbräuchliche Verwendung kompromittierter Token durch böswillige oder kompromittierte Ressourcen zu verhindern. Solche Anwendungen verfügen in der Regel über einen dedizierten sicheren Speicher für kryptografische Schlüssel.

DPoP kann verwendet werden, um Zugriffstoken an den Absender zu binden, unabhängig von der verwendeten Client-Authentifizierungsmethode; DPoP selbst wird jedoch nicht für die Client-Authentifizierung verwendet. DPoP kann auch verwendet werden, um Refresh-Token an den Absender zu binden, die an öffentliche Clients (d. h. Clients ohne Authentifizierungsdaten, die einer client_id zugeordnet sind) ausgegeben werden.

1.1. Konventionen und Terminologie

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so auszulegen, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn sie, wie hier, in Großbuchstaben erscheinen.

Diese Spezifikation verwendet die Augmented Backus-Naur Form (ABNF) Notation von [RFC5234].

Diese Spezifikation verwendet die Begriffe "Zugriffstoken" (Access Token), "Refresh-Token" (Refresh Token), "Autorisierungsserver" (Authorization Server), "Ressourcenserver" (Resource Server), "Autorisierungsendpunkt" (Authorization Endpoint), "Autorisierungsanforderung" (Authorization Request), "Autorisierungsantwort" (Authorization Response), "Token-Endpunkt" (Token Endpoint), "Grant-Typ" (Grant Type), "Zugriffstoken-Anforderung" (Access Token Request), "Zugriffstoken-Antwort" (Access Token Response), "Client", "öffentlicher Client" (Public Client) und "vertraulicher Client" (Confidential Client), die durch das "OAuth 2.0 Authorization Framework" [RFC6749] definiert sind.

Die Begriffe "Anforderung" (Request), "Antwort" (Response), "Header-Feld" (Header Field) und "Ziel-URI" (Target URI) stammen aus [RFC9110].

Die Begriffe "JOSE" und "JOSE Header" stammen aus [RFC7515].

Dieses Dokument enthält nicht-normative Beispiele für teilweise und vollständige HTTP-Nachrichten. Einige Beispiele verwenden einen einzelnen Backslash, um den Zeilenumbruch für lange Werte gemäß [RFC8792] anzuzeigen. Der umschließende Backslash sowie der folgende Zeilenumbruch und das führende Leerzeichen sind nicht Teil des Wertes.