4. DPoP Proof JWTs (DPoP-Proof-JWTs)

DPoP führt das Konzept eines DPoP-Proofs ein, bei dem es sich um ein JWT handelt, das vom Client erstellt und mit einer HTTP-Anforderung über das DPoP-Header-Feld gesendet wird. Jede HTTP-Anforderung erfordert einen eindeutigen DPoP-Proof.

Ein gültiger DPoP-Proof demonstriert dem Server, dass der Client den privaten Schlüssel besitzt, der zum Signieren des DPoP-Proof-JWT verwendet wurde. Dies ermöglicht es Autorisierungsservern, ausgegebene Token an den entsprechenden öffentlichen Schlüssel zu binden (wie in Abschnitt 5 beschrieben) und ermöglicht es Ressourcenservern, die Schlüsselbindung von Token, die sie erhalten, zu überprüfen (siehe Abschnitt 7.1), was verhindert, dass diese Token von einer Entität verwendet werden, die keinen Zugriff auf den privaten Schlüssel hat.

Ein DPoP-Proof ist der Nachweis des Besitzes eines Schlüssels und kein Authentifizierungs- oder Zugriffskontrollmechanismus per se. Wenn er in Kombination mit einem schlüsselgebundenen Zugriffstoken vorgelegt wird, wie in Abschnitt 7.1 beschrieben, bietet ein DPoP-Proof zusätzliche Sicherheit in Bezug auf die Legitimität des Clients, der das Zugriffstoken vorlegt. Ein gültiges DPoP-Proof-JWT reicht jedoch keinesfalls aus, um Zugriffskontrollentscheidungen zu treffen.

4.1. Der DPoP-HTTP-Header

Ein DPoP-Proof wird unter Verwendung des folgenden Anforderungsheaderfelds in eine HTTP-Anforderung aufgenommen:

DPoP: Ein JWT, der der Struktur und Syntax in Abschnitt 4.2 entspricht.

Abbildung 2 zeigt ein Beispiel für ein DPoP-HTTP-Headerfeld. Das Beispiel verwendet "\" für den Zeilenumbruch gemäß [RFC8792].

DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

                    Abbildung 2: Beispiel eines DPoP-Headers

Beachten Sie, dass Header-Feldnamen laut [RFC9110] nicht zwischen Groß- und Kleinschreibung unterscheiden; daher sind DPoP, DPOP und dpop alle gültige und äquivalente Header-Feldnamen. Die Groß-/Kleinschreibung des Header-Feldwerts ist jedoch signifikant.

Der Wert des DPoP-HTTP-Headerfelds verwendet die in Abschnitt 11.2 von [RFC9110] definierte token68-Syntax. Sie wird der Einfachheit halber in Abbildung 3 wiedergegeben.

DPoP       = token68
token68    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="

                   Abbildung 3: DPoP-Headerfeld-ABNF

4.2. Syntax des DPoP-Proof-JWT

Ein DPoP-Proof ist ein JWT [RFC7519], das (unter Verwendung von JSON Web Signature (JWS) [RFC7515]) mit einem vom Client gewählten privaten Schlüssel signiert ist (siehe unten). Der JOSE-Header eines DPoP-JWT MUSS mindestens die folgenden Parameter enthalten:

typ: Ein Feld mit dem Wert dpop+jwt, das das DPoP-Proof-JWT explizit typisiert, wie in Abschnitt 3.11 von [RFC8725] empfohlen.

alg: Ein Bezeichner für einen asymmetrischen digitalen JWS-Signaturalgorithmus aus [IANA.JOSE.ALGS]. Es DARF NICHT none oder ein Bezeichner für einen symmetrischen Algorithmus (Message Authentication Code (MAC)) sein.

jwk: Der öffentliche Schlüssel, der vom Client gewählt wurde, im JSON Web Key (JWK) Format [RFC7517], wie in Abschnitt 4.1.3 von [RFC7515] definiert. Er DARF NICHT den privaten Schlüssel enthalten.

Die Payload eines DPoP-Proof MUSS mindestens die folgenden Claims enthalten:

jti: Eindeutige Kennung für das DPoP-Proof-JWT. Der Wert MUSS so zugewiesen werden, dass die Wahrscheinlichkeit, dass derselbe Wert einem anderen DPoP-Proof zugewiesen wird, der während des Gültigkeitszeitraums des Proofs im selben Kontext verwendet wird, vernachlässigbar ist. Eine solche Eindeutigkeit kann durch Codierung (base64url oder eine andere geeignete Codierung) von mindestens 96 Bits pseudozufälliger Daten oder durch Verwendung eines Universally Unique Identifier (UUID)-Strings der Version 4 gemäß [RFC4122] erreicht werden. Der jti-Claim kann vom Server zur Erkennung und Verhinderung von Replay verwendet werden (siehe Abschnitt 11.1).

htm: Der Wert der HTTP-Methode ([RFC9110], Abschnitt 9.1) der Anforderung, an die das JWT angehängt ist.

htu: Der Wert der HTTP-URI ([RFC9110], Abschnitt 7.1) der Anforderung, an die das JWT angehängt ist, ohne Query- und Fragment-Teile.

iat: Zeitstempel der Erstellung des JWT ([RFC7519], Abschnitt 4.1.6).

Wenn der DPoP-Proof in Verbindung mit einem Zugriffstoken beim Zugriff auf eine geschützte Ressource verwendet wird (siehe Abschnitt 7), MUSS der DPoP-Proof auch den folgenden Claim enthalten:

ath: Hash des Zugriffstokens. Der Wert MUSS das Ergebnis einer base64url-Codierung (wie in Abschnitt 2 von [RFC7515] definiert) des SHA-256 [SHS] Hash der ASCII-Codierung des zugehörigen Zugriffstoken-Werts sein.

Wenn der Autorisierungsserver oder Ressourcenserver über den DPoP-Nonce-HTTP-Header einen Nonce bereitstellt (siehe Abschnitte 8 und 9), MUSS der DPoP-Proof auch den folgenden Claim enthalten:

nonce: Ein aktueller Nonce, der über den DPoP-Nonce-HTTP-Header bereitgestellt wurde.

Ein DPoP-Proof KANN andere JOSE-Header-Parameter oder Claims enthalten, je nach Erweiterungen, Profilen oder spezifischen Bereitstellungsanforderungen.

Abbildung 4 zeigt ein konzeptionelles Beispiel des decodierten Inhalts des DPoP-Proofs in Abbildung 2. Das JSON des JWT-Headers und der Payload wird gezeigt, der Signaturteil wird jedoch weggelassen. Wie üblich sind Zeilenumbrüche und zusätzliche Leerzeichen zur Formatierung und Lesbarkeit enthalten.

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"-BwC3ESc6acc2lTc",
  "htm":"POST",
  "htu":"https://server.example.com/token",
  "iat":1562262616
}

            Abbildung 4: Beispiel eines DPoP-Proof-JWT-Inhalts

Von der HTTP-Anforderung sind nur die HTTP-Methode und die URI im DPoP-JWT enthalten, und daher deckt der DPoP-Proof nur diese beiden Teile der Nachricht ab. Die Idee ist, nur genügend HTTP-Daten zu signieren, um einen angemessenen Besitznachweis für die HTTP-Anforderung zu erbringen. Dieser Designansatz, nur eine minimale Teilmenge der HTTP-Header-Daten zu verwenden, vermeidet die erheblichen Schwierigkeiten, die mit dem Versuch verbunden sind, HTTP-Nachrichten zu kanonisieren. Dennoch können DPoP-Proofs erweitert werden, um andere Informationen aus der HTTP-Anforderung zu enthalten (siehe auch Abschnitt 11.7).

4.3. Überprüfung von DPoP-Proofs

Um einen DPoP-Proof zu validieren, MUSS der empfangende Server sicherstellen, dass:

Es nur ein DPoP-HTTP-Anforderungsheaderfeld gibt.
Der Wert des DPoP-HTTP-Anforderungsheaderfelds ein einzelnes wohlgemerktes JWT ist.
Alle in Abschnitt 4.2 aufgeführten erforderlichen Claims im JWT enthalten sind.
Der Wert des typ JOSE-Header-Parameters dpop+jwt ist.
Der alg JOSE-Header-Parameter einen registrierten asymmetrischen digitalen Signaturalgorithmus [IANA.JOSE.ALGS] angibt, nicht none ist, von der Anwendung unterstützt wird und gemäß lokaler Richtlinien akzeptabel ist.
Die JWT-Signatur mit dem im jwk JOSE-Header-Parameter enthaltenen öffentlichen Schlüssel validiert wird.
Der jwk JOSE-Header-Parameter keinen privaten Schlüssel enthält.
Der htm Claim mit der HTTP-Methode der aktuellen Anforderung übereinstimmt.
Der htu Claim mit dem HTTP-URI-Wert der HTTP-Anforderung übereinstimmt, in der das JWT empfangen wurde, wobei Query- und Fragment-Teile ignoriert werden.
Wenn der Server dem Client einen Nonce-Wert bereitgestellt hat, der nonce Claim mit dem vom Server bereitgestellten Nonce-Wert übereinstimmt.
Die Erstellungszeit des JWT, bestimmt durch den iat Claim oder den vom Server über den nonce Claim verwalteten Zeitstempel, innerhalb eines akzeptablen Zeitfensters liegt (siehe Abschnitt 11.1).
Wenn es einer geschützten Ressource in Verbindung mit einem Zugriffstoken vorgelegt wird:
- der Wert des ath Claims gleich dem Hash dieses Zugriffstoken ist, und
- sichergestellt wird, dass der öffentliche Schlüssel, an den das Zugriffstoken gebunden ist, mit dem öffentlichen Schlüssel aus dem DPoP-Proof übereinstimmt.

Um die Wahrscheinlichkeit von False Positives zu verringern, SOLLTEN Server eine syntaxbasierte Normalisierung ([RFC3986], Abschnitt 6.2.2) und eine schemabasierte Normalisierung ([RFC3986], Abschnitt 6.2.3) anwenden, bevor sie den htu Claim vergleichen.

Diese Überprüfungen können in beliebiger Reihenfolge durchgeführt werden.