3. Concept (Konzept)

3. Concept (Konzept)

Die wichtigste Datenstruktur, die durch diese Spezifikation eingeführt wird, ist das DPoP-Proof-JWT (DPoP proof JWT), das als Header in einer HTTP-Anforderung gesendet wird, wie unten beschrieben. Der Client verwendet ein DPoP-Proof-JWT, um nachzuweisen, dass er den privaten Schlüssel besitzt, der einem bestimmten öffentlichen Schlüssel entspricht.

Grob gesprochen ist ein DPoP-Proof eine Signatur über:

• einige Daten der HTTP-Anforderung, an die er angehängt ist,

• einen Zeitstempel,

• eine eindeutige Kennung,

• eine optionale vom Server bereitgestellte Nonce, und

• einen Hash des zugehörigen Zugriffstokens, wenn ein Zugriffstoken in der Anforderung vorhanden ist.

+------------+                                      +---------------+
|            |--(A)-- Token-Anforderung ----------->|               |
| Client     |        (DPoP-Proof)                  | Autorisierungs|
|            |                                      | server        |
|            |<-(B)-- DPoP-gebundenes Zugriffstoken-|               |
|            |        (token_type=DPoP)             +---------------+
|            |
|            |
|            |                                      +---------------+
|            |--(C)-- DPoP-gebundenes Zugriffstoken>|               |
|            |        (DPoP-Proof)                  | Ressourcen-   |
|            |                                      | server        |
|            |<-(D)-- Geschützte Ressource ---------|               |
|            |                                      +---------------+
+------------+

                      Abbildung 1: Grundlegender DPoP-Ablauf

Die grundlegenden Schritte eines OAuth-Ablaufs mit DPoP (ohne optionale Nonce) sind in Abbildung 1 dargestellt.

A. In einer Token-Anforderung sendet der Client eine Autorisierungsberechtigung (z. B. einen Autorisierungscode, ein Refresh-Token usw.) an den Autorisierungsserver, um ein Zugriffstoken (und möglicherweise ein Refresh-Token) zu erhalten. Der Client fügt der Anforderung einen DPoP-Proof in einem HTTP-Header bei.

B. Der Autorisierungsserver bindet (sender-constrains) das Zugriffstoken an den öffentlichen Schlüssel, den der Client im DPoP-Proof beansprucht hat; d. h. das Zugriffstoken kann nicht ohne Nachweis des Besitzes des entsprechenden privaten Schlüssels verwendet werden. Wenn ein Refresh-Token an einen öffentlichen Client ausgegeben wird, wird es ebenfalls an den öffentlichen Schlüssel aus dem DPoP-Proof gebunden.

C. Um das Zugriffstoken zu verwenden, muss der Client den Besitz des privaten Schlüssels nachweisen, indem er der Anforderung erneut einen Header mit einem DPoP-Proof der Anforderung hinzufügt. Der Ressourcenserver muss Informationen über den öffentlichen Schlüssel erhalten, an den das Zugriffstoken gebunden ist. Diese Informationen können entweder direkt im Zugriffstoken kodiert sein (für JWT-strukturierte Zugriffstoken) oder über den Token-Introspektionsendpunkt (nicht dargestellt) bereitgestellt werden. Der Ressourcenserver überprüft, ob der öffentliche Schlüssel, an den das Zugriffstoken gebunden ist, mit dem öffentlichen Schlüssel des DPoP-Proofs übereinstimmt. Er verifiziert auch, dass der Hash des Zugriffstokens im DPoP-Proof mit dem in der Anforderung vorgelegten Zugriffstoken übereinstimmt.

D. Wenn die Signaturprüfung fehlschlägt oder die Daten im DPoP-Proof falsch sind (z. B. stimmt die Ziel-URI nicht mit dem URI-Claim im DPoP-Proof-JWT überein), verweigert der Ressourcenserver die Bedienung der Anforderung. Das Zugriffstoken selbst muss natürlich auch in jeder anderen Hinsicht gültig sein.

Der hier vorgeschlagene DPoP-Mechanismus ist keine Client-Authentifizierungsmethode. Tatsächlich ist einer der Hauptanwendungsfälle für DPoP öffentliche Clients (z. B. Single-Page-Anwendungen und Anwendungen auf Benutzergeräten), die keine Client-Authentifizierung verwenden. Dennoch ist DPoP so konzipiert, dass es mit private_key_jwt und allen anderen Client-Authentifizierungsmethoden kompatibel ist.

DPoP gewährleistet keine direkte Nachrichtenintegrität, sondern verlässt sich zu diesem Zweck auf die TLS-Schicht. Siehe Abschnitt 11 für weitere Details.