Zum Hauptinhalt springen

7. Protected Resource Access (Zugriff auf geschützte Ressourcen)

7. Protected Resource Access (Zugriff auf geschützte Ressourcen)​

Um mit DPoP auf eine geschützte Ressource zuzugreifen, muss die Anforderung sowohl den in Abschnitt 4 beschriebenen DPoP-Proof als auch das in Abschnitt 7.1 beschriebene Zugriffstoken enthalten. Der DPoP-Proof MUSS den ath Claim mit einem gültigen Hash-Wert des zugehörigen Zugriffstokens enthalten.

Durch die Bindung des Token-Werts an den Proof auf diese Weise wird verhindert, dass der Proof einer Anforderung in einer anderen Anforderung mit einem anderen Zugriffstoken-Wert verwendet werden kann. Wenn ein Client beispielsweise Token AT1 und AT2 besitzt, die an zwei verschiedene Ressourcenbesitzer gebunden sind, und für Interaktionen mit dem Autorisierungsserver denselben Schlüssel verwendet, könnten diese Token ausgetauscht werden. Ohne die durch das Feld ath bereitgestellte Bindung könnte eine für AT1 erfasste Signatur mit AT2 wiedergegeben werden, wodurch möglicherweise die Berechtigungen und der Zugriff der beabsichtigten Anforderung geändert würden. Bei Zugriffstoken, die innerhalb derselben Kombination aus Client und Ressourcenbesitzer rotiert werden, ist ein solcher Substitutionsschutz weiterhin wirksam, da jeder rotierte Token-Wert die Berechnung eines neuen Proofs erfordert. Diese Bindung stellt auch sicher, dass ein Proof, der zur Verwendung mit einem Zugriffstoken bestimmt ist, nicht ohne dieses Zugriffstoken verwendet werden kann und umgekehrt.

Der Ressourcenserver MUSS den Hash des präsentierten Token-Werts berechnen und überprüfen, ob er mit dem im Feld ath angegebenen Hash-Wert identisch ist (siehe Abschnitt 4.3). Da der Wert des Feldes ath durch die Signatur des DPoP-Proofs abgedeckt ist, bindet seine Einbeziehung den Zugriffstoken-Wert an den Besitzer des Schlüssels, der zur Erstellung der Signatur verwendet wurde.

Beachten Sie, dass das Feld ath allein nicht vor der Wiederverwendung (Replay) von DPoP-Proofs schützt und keine Bindung an die Anforderung bietet, mit der der Proof präsentiert wird. Das Zeitfenster der Überprüfung des Proofs und die enthaltenen Nachrichtenparameter, wie htm und htu, sind weiterhin wichtig.

7.1. Das DPoP-Authentifizierungsschema​

Ein DPoP-gebundenes Zugriffstoken wird unter Verwendung des Anforderungsheaderfelds Authorization mit dem Authentifizierungsschema DPoP gemäß Abschnitt 11.6.2 von [RFC9110] gesendet. Die Syntax des Authorization-Headerfelds für das DPoP-Schema verwendet die in Abschnitt 11.2 von [RFC9110] definierte token68-Syntax für Anmeldeinformationen, die der Einfachheit halber unten wiedergegeben wird. Die ABNF-Notationssyntax für Anmeldeinformationen des DPoP-Authentifizierungsschemas lautet wie folgt:

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

credentials = "DPoP" 1*SP token68

              Abbildung 12: DPoP-Authentifizierungsschema-ABNF

Für ein solches Zugriffstoken MUSS ein Ressourcenserver überprüfen, ob auch ein DPoP-Proof im DPoP-HTTP-Headerfeld der HTTP-Anforderung empfangen wurde, den DPoP-Proof gemäß den Regeln in Abschnitt 4.3 prüfen und überprüfen, ob der öffentliche Schlüssel des DPoP-Proofs mit dem öffentlichen Schlüssel übereinstimmt, an den das Zugriffstoken gemäß Abschnitt 6 gebunden ist.

Der Ressourcenserver DARF KEINEN Zugriff auf die Ressource gewähren, es sei denn, alle Überprüfungen sind erfolgreich.

Abbildung 13 zeigt ein Beispiel einer Anforderung an eine geschützte Ressource mit einem DPoP-gebundenen Zugriffstoken im Authorization-Header und dem DPoP-Proof im DPoP-Header. Das Beispiel verwendet "\" für den Zeilenumbruch gemäß [RFC8792]. Der decodierte Inhalt dieses DPoP-Proofs wird in Abbildung 14 gezeigt. Das JSON des JWT-Headers und der Payload wird gezeigt, der Signaturteil wird jedoch weggelassen. Wie üblich sind Zeilenumbrüche und Einrückungen zur Formatierung und Lesbarkeit enthalten.

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj\
 oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z\
 WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOCwiYXRoIjoiZlVIeU8ycjJaM0RaNTNF\
 c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E\
 OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA

              Abbildung 13: Anforderung an eine geschützte DPoP-Ressource
{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"e1j3V_bKic8-LAEB",
  "htm":"GET",
  "htu":"https://resource.example.org/protectedresource",
  "iat":1562262618,
  "ath":"fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

    Abbildung 14: Decodierter DPoP-Proof-JWT-Inhalt von Abbildung 13

Beim Empfang einer Anforderung ohne gültige Anmeldeinformationen oder mit unzureichenden Zugriffsinformationen für eine geschützte Ressource innerhalb eines Schutzraums, der DPoP-Authentifizierung erfordert, KANN der Server eine Antwort senden, die eine Aufforderung (Challenge) enthält, um DPoP-Authentifizierungsdaten vom Client anzufordern. Diese Aufforderung wird unter Verwendung des Antwortstatuscodes 401 (Unauthorized) ([RFC9110] Abschnitt 15.5.2) und des WWW-Authenticate-Headerfelds ([RFC9110] Abschnitt 11.6.1) gesendet. Der Server KANN den WWW-Authenticate-Header auch als Antwort auf andere Bedingungen einschließen.

In solchen Aufforderungen:

  • Der Schemaname ist DPoP.
  • Der Authentifizierungsparameter realm KANN enthalten sein, um den Schutzbereich anzugeben, wie in [RFC9110] Abschnitt 11.5 beschrieben.
  • Der in [RFC6750] Abschnitt 3 definierte Authentifizierungsparameter scope KANN enthalten sein.
  • Der Parameter error ([RFC6750] Abschnitt 3) SOLLTE enthalten sein, um den Grund anzugeben, warum die Anforderung abgelehnt wurde, wenn die Anforderung ein Zugriffstoken enthielt, aber bei der Authentifizierung fehlgeschlagen ist. Die in [RFC6750] Abschnitt 3.1 beschriebenen error-Parameterwerte sowie alle geeigneten Werte, die durch Erweiterungen definiert sind, sind anwendbar. Der Wert use_dpop_nonce kann verwendet werden, um zu signalisieren, dass in DPoP-Proofs für nachfolgende Anforderungen ein Nonce erforderlich ist, wie in Abschnitt 9 beschrieben. Zusätzlich wird invalid_dpop_proof verwendet, um anzuzeigen, dass der DPoP-Proof selbst gemäß den Kriterien von Abschnitt 4.3 als ungültig erachtet wurde.
  • Der Parameter error_description ([RFC6750] Abschnitt 3) KANN zusammen mit dem error-Parameter enthalten sein, um eine für Menschen lesbare Erklärung bereitzustellen, die für Entwickler und nicht für Endbenutzer gedacht ist.
  • Ein Parameter algs SOLLTE enthalten sein, um dem Client die JWS-Algorithmen zu signalisieren, die für DPoP-Proof-JWTs verwendet werden können. Der Wert dieses Parameters ist eine durch Leerzeichen getrennte Liste von JWS alg (Algorithmus) Header-Werten ([RFC7515] Abschnitt 4.1.1).
  • Andere Authentifizierungsparameter können verwendet werden; unbekannte Parameter MÜSSEN vom Empfänger ignoriert werden.

Abbildung 15 veranschaulicht eine Antwort auf eine Anforderung für eine geschützte Ressource ohne Authentifizierung.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP algs="ES256 PS256"

Abbildung 15: HTTP-401-Antwort auf eine Anforderung an eine geschützte Ressource ohne Authentifizierung

Abbildung 16 veranschaulicht eine Antwort auf eine Anforderung an eine geschützte Ressource, die aufgrund einer fehlgeschlagenen Überprüfung der DPoP-Bindung des Zugriffstokens abgelehnt wurde. Das Beispiel verwendet "\" für den Zeilenumbruch gemäß [RFC8792].

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="invalid_token", \
   error_description="Invalid DPoP key binding", algs="ES256"

  Abbildung 16: HTTP-401-Antwort auf eine Anforderung an eine geschützte Ressource mit ungültigem Token

Beachten Sie, dass browserbasierte Client-Anwendungen, die Cross-Origin Resource Sharing (CORS) [WHATWG.Fetch] verwenden, standardmäßig nur Zugriff auf die in der CORS-Sicherheitsliste aufgeführten HTTP-Antwortheader haben. Damit die Anwendung auf den WWW-Authenticate HTTP-Antwortheaderwert zugreifen und ihn verwenden kann, muss der Server ihn der Anwendung zur Verfügung stellen, indem er WWW-Authenticate in den Access-Control-Expose-Headers-Antwortheaderlistenwert aufnimmt.

Dieses Authentifizierungsschema ist nur für die Ursprungsserver-Authentifizierung bestimmt. Daher DARF dieses Authentifizierungsschema NICHT mit den Headerfeldern Proxy-Authenticate oder Proxy-Authorization verwendet werden.

Beachten Sie, dass die Syntax des Authorization-Headerfelds für dieses Authentifizierungsschema der Verwendung des Bearer-Schemas folgt, das in [RFC6750] Abschnitt 2.1 definiert ist. Obwohl dies nicht die bevorzugte Syntax für Anmeldeinformationen aus [RFC9110] Abschnitt 11.4 ist, ist sie mit dem dortigen allgemeinen Authentifizierungsframework kompatibel und wird aus Konsistenzgründen und zur Vertrautheit mit dem Bearer-Schema verwendet.

7.2. Kompatibilität mit dem Bearer-Authentifizierungsschema​

Geschützte Ressourcen, die sowohl DPoP- als auch Bearer-Schemata unterstützen, müssen die Verfahren zur Bewertung von Bearer-Token aktualisieren, um die herabgestufte Verwendung (Downgrade) von DPoP-gebundenen Zugriffstoken zu verhindern. Insbesondere MUSS eine solche geschützte Ressource ein DPoP-gebundenes Zugriffstoken ablehnen, das als Bearer-Token (gemäß [RFC6750]) empfangen wurde.

[RFC9110] Abschnitt 11.6.1 erlaubt es einer geschützten Ressource, die Unterstützung für mehrere Authentifizierungsschemata (d. h. Bearer und DPoP) über das WWW-Authenticate-Headerfeld einer 401 (Unauthorized) Antwort anzuzeigen.

Eine geschützte Ressource, die nur [RFC6750] unterstützt und DPoP nicht kennt, wird ein DPoP-gebundenes Zugriffstoken höchstwahrscheinlich als Bearer-Token akzeptieren (JWT [RFC7519] besagt, dass nicht erkannte Claims ignoriert werden; Introspection [RFC7662] besagt, dass andere Parameter vorhanden sein können, stellt jedoch keine funktionalen Anforderungen an deren Vorhandensein; und [RFC6750] schweigt effektiv zum Inhalt des Zugriffstokens in Bezug auf die Gültigkeit). Ein Client kann daher ein DPoP-gebundenes Zugriffstoken unter Verwendung des Bearer-Schemas senden, wenn er eine WWW-Authenticate: Bearer-Aufforderung von einer geschützten Ressource erhält (oder jederzeit, wenn er über Vorkenntnisse über die Fähigkeiten der geschützten Ressource verfügt). Dies kann die Logistik für ein schrittweises Upgrade auf DPoP-Unterstützung durch geschützte Ressourcen oder langfristige gemischte Bereitstellungen von Token-Typ-Unterstützung durch geschützte Ressourcen vereinfachen.

Wenn eine geschützte Ressource, die sowohl Bearer- als auch DPoP-Schemata unterstützt, mit mehreren WWW-Authenticate-Aufforderungen antworten möchte, sollte darauf geachtet werden, welche Aufforderung die tatsächlichen Fehlerinformationen übermittelt. Es wird empfohlen, die folgenden Regeln zu befolgen:

  • Wenn die Anforderung keine Anmeldeinformationen enthielt, sollten die Aufforderungen keine Fehlercodes oder andere Fehlerinformationen enthalten, wie in [RFC6750] Abschnitt 3.1 beschrieben (Abbildung 17).

  • Wenn der Mechanismus, mit dem die Authentifizierung versucht wurde, eindeutig festgestellt werden kann, sollte die entsprechende Aufforderung verwendet werden, um Fehlerinformationen zu übermitteln (Abbildung 18).

  • Andernfalls können sowohl Bearer- als auch DPoP-Aufforderungen verwendet werden, um Fehlerinformationen zu übermitteln (Abbildung 19).

Die folgenden Beispiele verwenden "\" für den Zeilenumbruch gemäß [RFC8792].

GET /protectedresource HTTP/1.1
Host: resource.example.org

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer, DPoP algs="ES256 PS256"

 Abbildung 17: HTTP-401-Antwort auf eine Anforderung an eine geschützte Ressource ohne Authentifizierung
GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer INVALID_TOKEN

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", \
    error_description="Invalid token", DPoP algs="ES256 PS256"

  Abbildung 18: HTTP-401-Antwort auf eine Anforderung an eine geschützte Ressource mit ungültiger Authentifizierung
GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU

HTTP/1.1 400 Bad Request
WWW-Authenticate: Bearer error="invalid_request", \
 error_description="Multiple methods used to include access token", \
 DPoP algs="ES256 PS256", error="invalid_request", \
 error_description="Multiple methods used to include access token"

  Abbildung 19: HTTP-400-Antwort auf eine Anforderung an eine geschützte Ressource mit mehrdeutiger Authentifizierung

7.3. Überlegungen für Clients​

Autorisierungsanforderungen, die DPoP-Proofs enthalten, sind möglicherweise nicht idempotent (abhängig von der Durchsetzung der jti-, iat- und nonce-Claims durch den Server). Dies macht Anforderungen an geschützte Ressourcen, die zuvor idempotent waren, nun möglicherweise nicht mehr idempotent. Es wird empfohlen, dass Clients eindeutige DPoP-Proofs erstellen, selbst wenn sie idempotente Anforderungen wiederholen, als Reaktion auf das, was typischerweise als vorübergehende HTTP-Fehler verstanden wird.

Clients, die häufig auf Netzwerkfehler stoßen, können bei der Interaktion mit Servern, die eine strengere Nonce-Validierung implementieren, vor zusätzlichen Herausforderungen stehen.

Letztes Update am