Nachweis des Besitzes ( DPoP )

DPoP bietet einen Mechanismus, mit dem ein Client auf den Absender beschränkte „ OAuth “-Token erhalten kann, indem er den Besitz eines öffentlichen-privaten Schlüsselpaars nachweist.

Die Spezifikation befindet sich im Entwurfsstadium: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-11.

DPoP HTTP Kopfzeile

Der Header „ DPoP “ ist ein signiertes JWT, das wichtige Informationen zum Besitznachweis enthält.

Der JOSE-Header des JWT unter DPoP muss mindestens die folgenden Parameter enthalten:

Parameter Beschreibung
Typ Der Typ des JWT. Dieser Wert muss „dpop+jwt“ lauten.
ALG Der Signaturalgorithmus. Die zulässigen Werte sind: RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512
JWK Ein JSON Web Key (JWK), der den öffentlichen Schlüssel darstellt. Darf keinen privaten Schlüssel enthalten.

Beispiel für einen JOSE-Header:

{
  "typ": "dpop+jwt",
  "alg": "RS256",
  "jwk": {
    "kty": "RSA",
    "n": "...",
    "e": "AQAB"
  }
}

Der Payload des JWT „ DPoP “ muss mindestens die folgenden Claims enthalten:

Name des Anspruchs Beschreibung
jti Eindeutige Kennung für dieses JWT.
htm Die Methode „ HTTP “ der Anfrage, an die das JWT angehängt ist.
htu Die Ziel-URI von „ HTTP “, ohne Abfrage- und Fragmentteile. Dies wäre der Endpunkt für die „Pushed Authorization Request“ (PAR) oder der Token-Endpunkt.
iat Erstellungszeitstempel des JWT.

Beispiel für eine JWT-Nutzlast:

{
  "jti": "3765f59c-43cd-4cf8-8180-73bc9ae4ff3c",
  "htm": "POST",
  "htu": "https://<tenant-hostname>/oauth2/token",
  "iat": 1661847227
}

Das JWT „ DPoP “ muss mit einem privaten Schlüssel signiert sein, und die Signatur muss mit dem öffentlichen Schlüssel überprüfbar sein, der im JOSE-Header des JWT angegeben ist. Das JWT darf nicht länger als 30 Minuten gültig sein. iatLiegt kein exp Anspruch vor, wird davon ausgegangen, dass dieses JWT 30 Minuten nach dem in angegebenen Erstellungszeitstempel abläuft.

Das JWT wird in einem Header namens DPoP[…] gesendet.

Beispiel für eine Anfrage:


curl -ki https://<tenantId>/oauth2/token
 -H "DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6Il..."
 -d "grant_type=client_credentials&client_secret=<secret>&client_id=<clientId>"

Authorize request

Die Autorisierungsanfrage enthält einen Fingerabdruck des JSON-Web-Schlüssels, entweder im Abfrageparameter oder im POST-Body.

Parameter Beschreibung
dpop_jkt Fingerabdruck des JSON-Web-Schlüssels, der dieser Autorisierungsanfrage zugeordnet werden soll.
https://<tenantId>/oauth2/authorize?grant_type=authorization_code&client_id=<clientId>&redirect_uri=<redirect_uri>&dpop_jkt=<dpop_jkt>&...

Der für diese Anfrage generierte Autorisierungscode wäre an diesen Fingerabdruck gebunden und würde bei der Token-Anfrage zur Validierung verwendet. Dadurch wird verhindert, dass der Autorisierungscode gestohlen und von einer anderen Instanz verwendet wird, die nicht über denselben privaten Schlüssel verfügt, um die Token-Anfrage beim Umtausch des Codes in Token zu signieren.

Es wird empfohlen, Pushed Authorization Requests (PAR) oder Request-Objekte in Verbindung mit „ DPoP, “ zu verwenden, um den dpop_jkt Fingerabdruck auf sichere Weise zu übermitteln. dpop_jktAlternativ kann bei PAR anstelle von der Header-Datei „ DPoP “ verwendet werden. Einzelheiten finden Sie DPoP HTTP header im obigen Abschnitt. Push-Autorisierungsanfragen können bei der Konfiguration der Anwendung „ OpenID Connect“ durch Auswahl Require pushed authorization request (PAR) von erzwungen werden.

Token-Anfrage

Anfragen für Zugriffs- und Aktualisierungstoken müssen den Header „ DPoP “ HTTP enthalten. Einzelheiten finden Sie DPoP HTTP header im obigen Abschnitt.

Beim Autorisierungscode-Ablauf muss der Fingerabdruck dieses JWK mit dem JWK-Fingerabdruck (dpop_jkt) übereinstimmen, der bei der Autorisierungsanfrage gesendet wurde.

Beispiel für eine Anfrage:


curl -ki https://<tenantId>/oauth2/token
 -H "DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6Il..."
 -d "grant_type=client_credentials&client_secret=<secret>&client_id=<clientId>"

Das Ergebnis dieses Ablaufs ist eine Reihe von Token, die an den Besitznachweis gebunden sind. Dies lässt sich durch eine Token-Introspektion überprüfen.

Token-Introspektion

Wenn ein Zugriffstoken von „ DPoP “ analysiert wird, werden zusätzliche Claims zurückgegeben.
  • DPoPtoken_type: Anstelle von bearer wäre dieser Wert.
  • cnf: Die JWK-Daumenabdruck-Bestätigung gibt einen Hash des öffentlichen Schlüssels zurück.
Von Clients, die das Token überprüfen, wird erwartet, dass sie die „ DPoP “-Bindung des Zugriffstokens validieren, indem sie den Hash des öffentlichen Schlüssels mit dem cnf entsprechenden jkt Anspruch in der Antwort auf die Überprüfung vergleichen.

Beispiel für eine Introspektionsantwort:


{
    ...,
    "cnf": {
        "jkt": "yrFAH18WFPml9e9IIo6rB_fLdFX1pdbMgIcd_fW_4aM="
    },
    "token_type": "DPoP",
    ...
}