Nachweis des Besitzes ( DPoP )

Online bearbeiten

DPoP bietet einen Mechanismus, mit dem ein Client durch Vorlage eines Nachweises über den Besitz eines öffentlichen und privaten Schlüsselpaars vom Absender beschränkte „ OAuth ”-Token erhalten kann.

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

DPoP HTTP

Der Header DPoP ist ein signiertes JWT, das Schlüsselinformationen für den Nachweis des Besitzes enthält.

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


Parameter	Beschreibung
Typ	Der Typ des JWT. Dieser Wert muss "dpop + jwt" lauten.
ALG	Der Signaturalgorithmus. Gültige 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 JOSE-Header:

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

Die Nutzdaten des JWT DPoP müssen mindestens die folgenden Deklarationen enthalten:


Name des Anspruchs	Beschreibung
jti	Eindeutige Kennung für dieses JWT.
Htm	HTTP der Anfrage, an die das JWT angehängt ist.
HTML	HTTP ohne Abfrage- und Fragmentteile. Dies wäre der PAR-Endpunkt (Pushed Authorization Request) oder Tokenendpunkt.
iat	Erstellungszeitmarke des JWT.

Beispiel für JWT-Nutzdaten:

{
  "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 verifizierbar sein, der im JOSE-Header des JWT bereitgestellt wird. Das JWT darf nicht länger als 30 Minuten gültig sein. Wenn es keinen exp -Anspruch gibt, wird davon ausgegangen, dass der Ablauf für dieses JWT 30 Minuten nach der in iatangegebenen Erstellungszeitmarke liegt.

Das JWT wird in einem Header namens DPoPgesendet.

Anforderungsbeispiel:


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

Authorize request

Die Berechtigungsanforderung enthält einen Fingerabdruck des JSON Web Key im Abfrageparameter oder POST-Hauptteil.


Parameter	Beschreibung
dpop_jktunit description in lists	Fingerabdruck des JSON Web Key, der dieser Berechtigungsanforderung 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 Anforderung generierte Berechtigungscode wird an diesen Fingerabdruck gebunden und für die Validierung bei der Tokenanforderung verwendet. Dadurch wird verhindert, dass der Berechtigungscode gestohlen und von etwas anderem verwendet wird, das nicht denselben privaten Schlüssel zum Signieren der Tokenanforderung hat, wenn der Code gegen Token ausgetauscht wird.

Es wird empfohlen, Pushed Authorization Requests (PAR) oder Request-Objekte in Verbindung mit zu verwenden, um den dpop_jkt DPoP, Fingerabdruck auf sichere Weise zu senden. Alternativ kann mit PAR der Header DPoP anstelle von dpop_jktverwendet werden. Details finden Sie im Abschnitt DPoP HTTP header weiter oben. Mit Push-Operation übertragene Berechtigungsanforderungen können erzwungen werden, indem beim Konfigurieren der OpenID Connect-Anwendung Require pushed authorization request (PAR) ausgewählt wird.

Tokenanforderung

Anfragen für Zugriffs- und Aktualisierungstoken müssen HTTP enthalten. Details finden Sie im Abschnitt DPoP HTTP header weiter oben.

Für den Berechtigungscodeablauf muss der Fingerabdruck dieses JWK mit dem JWK-Fingerabdruck (dpop_jkt) übereinstimmen, der während der Berechtigungsanforderung gesendet wurde.

Anforderungsbeispiel:


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

Das Ergebnis dieser Ausführung ist eine Gruppe von Tokens, die an den Nachweis des Besitzes gebunden sind. Dies kann mit Tokenintrospektion validiert werden.

Tokenintrospektion

Wenn ein DPoP -Zugriffstoken überwacht wird, werden zusätzliche Ansprüche zurückgegeben.

token_type: Anstelle von bearerlautet dieser Wert DPoP.
cnf: Der JWK-Piktogrammbestätigungsanspruch gibt einen Hashwert des öffentlichen Schlüssels zurück.

Clients, die das Token introspektieren, müssen die DPoP -Bindung des Zugriffstokens validieren, indem sie den Hashwert des öffentlichen Schlüssels mit dem cnf jkt -Anspruch in der Introspektionsantwort vergleichen.

Beispielintrospektionsantwort:


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