6. Public Key Confirmation (Bestätigung des öffentlichen Schlüssels)

Ressourcenserver MÜSSEN in der Lage sein, zuverlässig zu identifizieren, ob ein Zugriffstoken ein DPoP-gebundenes Token ist, und wenn ja, ausreichende Informationen zu bestimmen, um seine Bindung an den DPoP-Proof zu überprüfen (siehe Abschnitt 7.1). Diese Bindung wird erreicht, indem der öffentliche Schlüssel so mit dem Token verknüpft wird, dass die geschützte Ressource darauf zugreifen kann; z. B. durch direkte Einbettung des JWK-Hashs in das ausgegebene Zugriffstoken unter Verwendung der in Abschnitt 6.1 beschriebenen Syntax oder durch Token-Introspektion wie in Abschnitt 6.2 beschrieben. Andere Methoden zur Verknüpfung eines öffentlichen Schlüssels mit einem Zugriffstoken sind nach Vereinbarung zwischen dem Autorisierungsserver und der geschützten Ressource möglich, liegen jedoch außerhalb des Geltungsbereichs dieser Spezifikation.

Ressourcenserver, die DPoP unterstützen, MÜSSEN sicherstellen, dass der öffentliche Schlüssel aus dem DPoP-Proof mit dem öffentlichen Schlüssel übereinstimmt, an den das Zugriffstoken gebunden ist.

6.1. JWK-Thumbprint-Bestätigungsmethode

Wenn Zugriffstoken als JWTs [RFC7519] dargestellt werden, werden die Informationen über den öffentlichen Schlüssel mithilfe des hier definierten jkt Bestätigungsmethoden-Members dargestellt. Um den Hash eines öffentlichen Schlüssels innerhalb eines JWT zu übermitteln, führt diese Spezifikation das folgende JWT-Confirmation-Method [RFC7800] Member ein, das unter dem cnf Claim verwendet werden soll:

jkt: JWK SHA-256 Thumbprint Bestätigungsmethode. Der Wert des jkt-Members MUSS die base64url-Codierung (wie in [RFC7515] definiert) des JWK SHA-256 Thumbprint (gemäß [RFC7638]) des öffentlichen DPoP-Schlüssels (im JWK-Format) sein, an den das Zugriffstoken gebunden ist.

Das folgende Beispiel-JWT in Abbildung 8 (mit decodierter JWT-Payload in Abbildung 9) enthält einen cnf-Claim mit dem jkt JWK-Thumbprint-Bestätigungsmethoden-Member. Der jkt-Wert in diesen Beispielen ist der Hash des öffentlichen Schlüssels aus dem in den Beispielen in Abschnitt 5 gezeigten DPoP-Proof. Das Beispiel verwendet "\" für den Zeilenumbruch gemäß [RFC8792].

eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWIiOiJzb21lb25lQGV4YW1\
wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJuYmYiOjE\
1NjIyNjI2MTEsImV4cCI6MTU2MjI2NjIxNiwiY25mIjp7ImprdCI6IjBaY09DT1JaTll\
5LURXcHFxMzBqWnlKR0hUTjBkMkhnbEJWM3VpZ3VBNEkifX0.3Tyo8VTcn6u_PboUmAO\
YUY1kfAavomW_YwYMkmRNizLJoQzWy2fCo79Zi5yObpIzjWb5xW4OGld7ESZrh0fsrA

    Abbildung 8: JWT mit JWK SHA-256 Thumbprint Bestätigung

{
  "sub":"[email protected]",
  "iss":"https://server.example.com",
  "nbf":1562262611,
  "exp":1562266216,
  "cnf":
  {
    "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

 Abbildung 9: JWT-Claim-Set mit JWK SHA-256 Thumbprint Bestätigung

6.2. JWK-Thumbprint-Bestätigungsmethode bei der Token-Introspektion

"OAuth 2.0 Token Introspection" [RFC7662] definiert eine Methode für eine geschützte Ressource, um einen Autorisierungsserver nach dem Aktivitätsstatus eines Zugriffstokens zu fragen und Meta-Informationen über das Token zu ermitteln.

Bei einem DPoP-gebundenen Zugriffstoken wird der Hash des öffentlichen Schlüssels, an den das Token gebunden ist, als Meta-Information in einer Token-Introspektionsantwort an die geschützte Ressource übermittelt. Der Hash wird unter Verwendung derselben jkt-Memberstruktur innerhalb eines cnf-Inhalts übermittelt, wie für die JWK-Thumbprint-Bestätigungsmethode in Abschnitt 6.1 beschrieben, als Top-Level-Member der Introspektionsantwort-JSON. Beachten Sie, dass der Ressourcenserver keinen DPoP-Proof mit der Introspektionsanforderung sendet und der Autorisierungsserver die DPoP-Bindung des Zugriffstokens am Introspektionsendpunkt nicht validiert. Vielmehr verwendet der Ressourcenserver die Daten der Introspektionsantwort, um die Bindung des Zugriffstokens selbst lokal zu validieren.

Wenn die Introspektionsantwort ein token_type-Member enthält, MUSS dessen Wert DPoP sein.

Die folgende Beispiel-Introspektionsanforderung in Abbildung 10 und die entsprechende Antwort in Abbildung 11 veranschaulichen einen Introspektionsaustausch für das Beispiel des in Abbildung 6 ausgestellten DPoP-gebundenen Zugriffstokens.

POST /as/introspect.oauth2 HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic cnM6cnM6TWt1LTZnX2xDektJZHo0ZnNON2tZY3lhK1Rp

token=Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU

               Abbildung 10: Beispiel einer Introspektionsanforderung

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "active": true,
  "sub": "[email protected]",
  "iss": "https://server.example.com",
  "nbf": 1562262611,
  "exp": 1562266216,
  "cnf":
  {
    "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

      Abbildung 11: Beispiel einer Introspektionsantwort für ein DPoP-gebundenes Zugriffstoken