Zum Hauptinhalt springen

10. Authorization Code Binding to a DPoP Key (Bindung des Autorisierungscodes an einen DPoP-Schlüssel)

10. Authorization Code Binding to a DPoP Key (Bindung des Autorisierungscodes an einen DPoP-Schlüssel)

Die Bindung des an einen Client ausgegebenen Autorisierungscodes an seinen Proof-of-Possession-Schlüssel ermöglicht eine End-to-End-Bindung des gesamten Autorisierungsablaufs. Diese Spezifikation definiert zu diesem Zweck den Autorisierungsanforderungsparameter dpop_jkt. Der Wert des dpop_jkt Autorisierungsanforderungsparameters ist der [RFC7638] JWK SHA-256 Thumbprint des öffentlichen Schlüssels zum Proof-of-Possession, was derselbe Wert ist, der für die in Abschnitt 6.1 definierte jkt Bestätigungsmethode verwendet wird.

Beim Empfang einer Token-Anforderung berechnet der Autorisierungsserver den JWK-Thumbprint des öffentlichen Schlüssels zum Proof-of-Possession im DPoP-Proof und überprüft, ob er mit dem Wert des dpop_jkt Parameters in der Autorisierungsanforderung übereinstimmt. Ist dies nicht der Fall, MUSS der Autorisierungsserver die Anforderung ablehnen.

Ein Beispiel für eine Autorisierungsanforderung unter Verwendung des dpop_jkt Autorisierungsanforderungsparameters ist unten dargestellt. Das Beispiel verwendet "\" für den Zeilenumbruch gemäß [RFC8792].

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz\
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM\
&code_challenge_method=S256\
&dpop_jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs HTTP/1.1
Host: server.example.com

Abbildung 25: Autorisierungsanforderung mit dpop_jkt Parameter

Die Verwendung des dpop_jkt Autorisierungsanforderungsparameters ist OPTIONAL. Beachten Sie, dass der dpop_jkt Autorisierungsanforderungsparameter in Verbindung mit Proof Key for Code Exchange (PKCE) [RFC7636] verwendet werden kann, was in [SECURITY-TOPICS] als Gegenmaßnahme gegen die Injektion von Autorisierungscodes empfohlen wird. Der dpop_jkt Autorisierungsanforderungsparameter bietet einen ähnlichen Schutz nur dann, wenn für jede Autorisierungsanforderung ein eindeutiger DPoP-Schlüssel verwendet wird.

10.1. DPoP mit Pushed Authorization Requests

Wenn Pushed Authorization Requests (PAR) [RFC9126] in Verbindung mit DPoP verwendet werden, gibt es zwei Möglichkeiten, den DPoP-Schlüssel in der PAR-Anforderung zu kommunizieren:

  • Der Parameter dpop_jkt kann wie in Abschnitt 10 beschrieben verwendet werden, um den ausgestellten Autorisierungscode an einen bestimmten Schlüssel zu binden. In diesem Fall MUSS dpop_jkt zusammen mit den anderen Autorisierungsanforderungsparametern im POST-Body der PAR-Anforderung enthalten sein.
  • Alternativ kann der PAR-Anforderung ein DPoP-Header hinzugefügt werden. In diesem Fall MUSS der Autorisierungsserver das bereitgestellte DPoP-Proof-JWT wie in Abschnitt 4.3 definiert überprüfen und SO verfahren, als ob der enthaltene öffentliche Schlüssel-Thumbprint unter Verwendung von dpop_jkt bereitgestellt worden wäre; d. h. spätere Token-Anforderungen ablehnen, es sei denn, es wird ein DPoP-Proof für denselben Schlüssel bereitgestellt. Dies vereinfacht die Client-Implementierung, da er allen Anforderungen an den Autorisierungsserver "blind" einen DPoP-Header anhängen kann, unabhängig vom Typ der Anforderung. Außerdem bietet dies eine stärkere Bindung, da der DPoP-Header einen Nachweis des Besitzes des privaten Schlüssels enthält.

Autorisierungsserver, die PAR und DPoP unterstützen, MÜSSEN beide Mechanismen unterstützen. Wenn beide Mechanismen gleichzeitig verwendet werden, MUSS der Autorisierungsserver die Anforderung ablehnen, wenn der JWK-Thumbprint in dpop_jkt nicht mit dem öffentlichen Schlüssel im DPoP-Header übereinstimmt.

Die Zulassung beider Mechanismen stellt sicher, dass Clients, die dpop_jkt verwenden, Pushed Authorization Requests nicht anders behandeln müssen als Autorisierungsanforderungen über den Front-Channel, während Clients mit einem einzigen Codepfad zur Sicherung aller Aufrufe an Endpunkte des Autorisierungsservers es ermöglicht wird, Anforderungen an den PAR-Endpunkt nicht von Anforderungen an den Token-Endpunkt unterscheiden zu müssen.