Zum Hauptinhalt springen

8. Authorization Server-Provided Nonce (Vom Autorisierungsserver bereitgestellte Nonce)

8. Authorization Server-Provided Nonce (Vom Autorisierungsserver bereitgestellte Nonce)​

Dieser Abschnitt spezifiziert einen Mechanismus zur Verwendung einer vom Server bereitgestellten, undurchsichtigen Nonce, um die Lebensdauer von DPoP-Proofs zu begrenzen. Wenn kein solcher Mechanismus verwendet wird, kann eine böswillige Partei, die den Client kontrolliert (einschließlich möglicherweise des Endbenutzers), DPoP-Proofs erstellen, die zu jedem beliebigen Zeitpunkt in der Zukunft verwendbar sind.

Die Aufnahme eines vom Autorisierungsserver stammenden Nonce-Wertes in den DPoP-Proof KANN vom Autorisierungsserver verwendet werden, um die Lebensdauer von DPoP-Proofs zu begrenzen. Es liegt im Ermessen des Servers, wann er eine neue DPoP-Nonce-Aufforderung ausgibt und wann er eine solche verlangt, d. h. die Verwendung des Nonce-Wertes in nachfolgenden DPoP-Proofs vorschreibt. Die Logik, nach der ein Server diese Entscheidung trifft, liegt außerhalb des Geltungsbereichs dieses Dokuments.

Ein Autorisierungsserver KANN einen Nonce-Wert bereitstellen, den der Client in gesendete DPoP-Proofs aufnehmen muss. Er tut dies, indem er auf eine Anforderung ohne Nonce mit einer HTTP 400 (Bad Request) Fehlerantwort mit use_dpop_nonce als Fehlercode-Wert antwortet, wie in Abschnitt 5.2 von [RFC6749] spezifiziert. Der Autorisierungsserver fügt der Antwort einen DPoP-Nonce-Header hinzu, der einen Nonce-Wert bereitstellt, der beim Senden nachfolgender Anforderungen verwendet werden soll. Der Nonce-Wert MUSS unvorhersehbar sein. Dieser Fehlercode wird auch verwendet, um einen neuen Nonce-Wert bereitzustellen, falls eine Nonce-Abweichung auftritt. Der Client empfängt normalerweise einen use_dpop_nonce-Fehler und den begleitenden Nonce-Wert und wiederholt die Anforderung mit dem neuen bereitgestellten Nonce-Wert.

Zum Beispiel kann der Autorisierungsserver als Antwort auf eine Token-Anforderung ohne Nonce, wenn der Autorisierungsserver eine Nonce verlangt, einen DPoP-Nonce-Wert wie den folgenden zurückgeben, um einen Nonce-Wert zur Aufnahme in den DPoP-Proof bereitzustellen:

HTTP/1.1 400 Bad Request
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v

{
 "error": "use_dpop_nonce",
 "error_description":
   "Authorization server requires nonce in DPoP proof"
}

  Abbildung 20: HTTP-400-Antwort auf eine Token-Anforderung ohne Nonce

Andere HTTP-Header oder JSON-Felder KÖNNEN in der Fehlerantwort enthalten sein, es DARF jedoch NICHT mehr als einen DPoP-Nonce-Header geben.

Nach Erhalt einer Nonce wird erwartet, dass der Client die Token-Anforderung erneut versucht und dabei einen DPoP-Proof verwendet, der den bereitgestellten Nonce-Wert im nonce Claim des DPoP-Proofs enthält. Hier ist ein Beispiel für eine decodierte JWT-Payload für einen solchen DPoP-Proof, der die Nonce enthält:

{
 "jti": "-BwC3ESc6acc2lTc",
 "htm": "POST",
 "htu": "https://server.example.com/token",
 "iat": 1562262616,
 "nonce": "eyJ7S_zG.eyJH0-Z.HX4w-7v"
}

       Abbildung 21: DPoP-Proof-Payload mit Nonce-Wert

Die Nonce ist für den Client opak (undurchsichtig).

Wenn der nonce Claim eines DPoP-Proofs nicht genau mit einer Nonce übereinstimmt, die dem Client kürzlich vom Autorisierungsserver bereitgestellt wurde, MUSS der Autorisierungsserver die Anforderung ablehnen. Die Ablehnungsantwort KANN einen DPoP-Nonce-HTTP-Header enthalten, der einen neuen Nonce-Wert bereitstellt, der für nachfolgende Anforderungen verwendet werden soll.

Die Absicht ist, dass der Client nur einen einzigen Nonce-Wert beibehalten muss und der Server ein Fenster kürzlich verwendeter Nonces vorhält. Dennoch kann es zu vorübergehenden Situationen kommen, in denen die vom Server und vom Client gespeicherten Nonce-Werte nicht synchron sind. Diese Situation korrigiert sich jedoch von selbst: Mit einer Ablehnungsnachricht kann der Server dem Client den Nonce-Wert senden, den er verwendet sehen möchte, und den der Client speichern und für einen erneuten Versuch der Anforderung verwenden kann. Selbst wenn der Client oder Server ihren gespeicherten Nonce-Wert verwirft, korrigiert sich die Situation ebenfalls von selbst, da bei der Antwort auf eine fehlgeschlagene Anforderung oder bei einem erneuten Versuch ein neuer Nonce-Wert kommuniziert werden kann.

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 DPoP-Nonce HTTP-Antwortheaderwert zugreifen und ihn verwenden kann, muss der Server ihn der Anwendung zur Verfügung stellen, indem er DPoP-Nonce in den Access-Control-Expose-Headers-Antwortheaderlistenwert aufnimmt.

8.1. Nonce-Syntax​

Die ABNF-Syntax für die Nonce (die die gleiche ist wie die scope-token-Syntax) aus [RFC6749] lautet wie folgt:

nonce = 1*NQCHAR

                        Abbildung 22: Nonce-ABNF

8.2. Bereitstellung eines neuen Nonce-Wertes​

Der Autorisierungsserver entscheidet, wann er dem Client einen neuen Nonce-Wert zur Verwendung bereitstellt. Es wird erwartet, dass der Client eine vorhandene bereitgestellte Nonce in DPoP-Proofs verwendet, bis der Server einen neuen Nonce-Wert bereitstellt.

Der Autorisierungsserver KANN eine neue Nonce auf die gleiche Weise bereitstellen, wie die anfängliche Nonce bereitgestellt wurde – unter Verwendung eines DPoP-Nonce-HTTP-Headers in einer Antwort. Das DPoP-Nonce-HTTP-Headerfeld verwendet die in Abschnitt 8.1 definierte Nonce-Syntax. Jedes Mal, wenn dies geschieht, ist ein zusätzlicher Protokoll-Roundtrip erforderlich.

Es wird auch eine effizientere Methode zur Bereitstellung eines neuen Nonce-Wertes definiert, die darin besteht, den DPoP-Nonce-HTTP-Header in die HTTP-200 (OK) Antwort einer vorherigen Anforderung aufzunehmen. Der Client MUSS den neu bereitgestellten Nonce-Wert für die nächste Token-Anforderung und alle nachfolgenden Token-Anforderungen verwenden, bis der Autorisierungsserver eine neue Nonce bereitstellt.

Antworten, die einen DPoP-Nonce-HTTP-Header enthalten, SOLLTEN nicht zwischenspeicherbar sein (z. B. durch Verwendung von Cache-Control: no-store in einer Antwort auf eine GET-Anforderung), um zu verhindern, dass die Antwort zur Bedienung einer nachfolgenden Anforderung verwendet wird und folglich ein veralteter Nonce-Wert verwendet wird.

Hier ist ein Beispiel für eine 200 OK Antwort, die den nächsten Nonce-Wert bereitstellt:

HTTP/1.1 200 OK
Cache-Control: no-store
DPoP-Nonce: eyJ7S_zG.eyJbYu3.xQmBj-1

    Abbildung 23: HTTP-200-Antwort mit Bereitstellung des nächsten Nonce-Wertes
Letztes Update am