5. DPoP Access Token Request (DPoP-Zugriffstoken-Anforderung)

Um ein an einen öffentlichen Schlüssel gebundenes Zugriffstoken mit DPoP anzufordern, MUSS der Client bei einer Zugriffstoken-Anforderung an den Token-Endpunkt des Autorisierungsservers ein gültiges DPoP-Proof-JWT in einem DPoP-Header bereitstellen. Dies gilt für alle Zugriffstoken-Anforderungen, unabhängig vom Grant-Typ (z. B. die üblichen Grant-Typen authorization_code und refresh_token sowie Erweiterungs-Grant-Typen wie JWT Authorization Grant [RFC7523]). Die HTTP-Anforderung in Abbildung 5 veranschaulicht eine solche Zugriffstoken-Anforderung unter Verwendung des Autorisierungscode-Grants und unter Einbeziehung eines DPoP-Proof-JWT im DPoP-Header. Das Beispiel verwendet "\" für den Zeilenumbruch gemäß [RFC8792].

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

grant_type=authorization_code\
&client_id=s6BhdRkqt\
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\
&code_verifier=bEaL42izcC-o-xBk0K2vuJ6U-y1p9r_wW2dFWIWgjz-

 Abbildung 5: Token-Anforderung für ein DPoP-Sendergebundenes Token mittels Autorisierungscode

Das DPoP-HTTP-Headerfeld MUSS ein gültiges DPoP-Proof-JWT enthalten. Wenn der DPoP-Proof ungültig ist, gibt der Autorisierungsserver eine Fehlerantwort gemäß Abschnitt 5.2 von [RFC6749] mit dem Fehlerparameterwert invalid_dpop_proof zurück.

Nach Prüfung des DPoP-Proofs auf Gültigkeit verknüpft der Autorisierungsserver zur Senderbindung des Zugriffstokens das ausgegebene Zugriffstoken mit dem öffentlichen Schlüssel aus dem DPoP-Proof. Dies kann wie in Abschnitt 6 beschrieben erfolgen. Die Zugriffstoken-Antwort MUSS einen token_type von DPoP enthalten, um dem Client anzuzeigen, dass das Zugriffstoken an den DPoP-Schlüssel gebunden wurde und wie in Abschnitt 7.1 beschrieben verwendet werden kann. Die Beispielantwort in Abbildung 6 veranschaulicht eine solche Antwort.

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

{
 "access_token": "Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU",
 "token_type": "DPoP",
 "expires_in": 2677,
 "refresh_token": "Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g"
}

                   Abbildung 6: Zugriffstoken-Antwort

Die Beispielantwort in Abbildung 6 enthält ein Refresh-Token, das der Client verwenden kann, um ein neues Zugriffstoken zu erhalten, wenn das alte abläuft. Das Aktualisieren eines Zugriffstokens ist eine Token-Anforderung an den Token-Endpunkt des Autorisierungsservers unter Verwendung des Grant-Typs refresh_token. Wie bei allen Zugriffstoken-Anforderungen macht der Client dies zu einer DPoP-Anforderung, indem er einen DPoP-Proof einfügt, wie in Abbildung 7 gezeigt. Das Beispiel verwendet "\" für den Zeilenumbruch gemäß [RFC8792].

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjY1Mjk2fQ.pAqut2IRDm_De6PR93SYmGBPXpwrAk90e8cP2hjiaG5Qs\
 GSuKDYW7_X620BxqhvYC8ynrrvZLTk41mSRroapUA

grant_type=refresh_token\
&client_id=s6BhdRkqt\
&refresh_token=Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g

 Abbildung 7: Token-Anforderung für ein DPoP-gebundenes Token mittels Refresh-Token

Wenn ein Autorisierungsserver, der DPoP unterstützt, einem öffentlichen Client ein Refresh-Token ausstellt, der einen gültigen DPoP-Proof am Token-Endpunkt vorlegt, MUSS das Refresh-Token an den entsprechenden öffentlichen Schlüssel gebunden werden. Wenn das Refresh-Token anschließend verwendet wird, um ein neues Zugriffstoken zu erhalten, MUSS diese Bindung validiert werden. Ein solcher Client MUSS daher jedes Mal, wenn dieses Refresh-Token zum Abrufen eines neuen Zugriffstokens verwendet wird, einen DPoP-Proof mit demselben Schlüssel vorlegen, der zum Abrufen des Refresh-Tokens verwendet wurde. Die Implementierungsdetails der Bindung des Refresh-Tokens liegen im Ermessen des Autorisierungsservers; es gibt keine Interoperabilitätsüberlegungen für die spezifischen Details der Bindung, da der Autorisierungsserver das Refresh-Token sowohl generiert als auch validiert.

Der Autorisierungsserver KANN wählen, ein nicht an DPoP gebundenes Zugriffstoken auszustellen, indem er den Wert Bearer ([RFC6750]) im Parameter token_type der Zugriffstoken-Antwort verwendet. Für öffentliche Clients, die auch ein Refresh-Token erhalten, hat dies immer noch den Effekt, dass nur das Refresh-Token DPoP-gebunden ist, was die Sicherheitslage dennoch verbessern kann, auch wenn geschützte Ressourcen noch nicht aktualisiert wurden, um DPoP zu unterstützen.

Wenn die Zugriffstoken-Antwort einen anderen token_type-Wert als DPoP enthält, erhält der Client nicht den Schutz für Zugriffstoken, den DPoP bietet. Wenn dieser Schutz wichtig für die Sicherheit der Anwendung ist, MUSS der Client die Antwort verwerfen. Andernfalls kann der Client wie bei einer normalen OAuth-Interaktion fortfahren.

Refresh-Token, die an vertrauliche Clients (d. h. Clients, die Authentifizierungsdaten beim Autorisierungsserver hinterlegt haben) ausgegeben werden, sind NICHT an den öffentlichen Schlüssel aus dem DPoP-Proof gebunden, da sie bereits durch einen anderen bestehenden Mechanismus sendergebunden sind. Das OAuth 2.0 Authorization Framework [RFC6749] erfordert bereits, dass der Autorisierungsserver Refresh-Token an den Client bindet, an den sie ausgegeben wurden, und vertrauliche Clients authentifizieren sich beim Autorisierungsserver, wenn sie das Refresh-Token vorlegen. Infolgedessen sind solche Refresh-Token durch die Client-ID und die zugehörige Authentifizierungsanforderung sendergebunden. Dieser bestehende Senderbindungsmechanismus ist flexibler als eine direkte Bindung an einen bestimmten öffentlichen Schlüssel (er ermöglicht z. B. die Rotation von Client-Anmeldeinformationen, ohne die Refresh-Token ungültig zu machen).

5.1. Metadaten des Autorisierungsservers

Dieses Dokument führt die folgenden Metadatenparameter für Autorisierungsserver [RFC8414] ein, um die allgemeine Unterstützung für DPoP und die spezifischen JWS alg-Werte zu signalisieren, die der Autorisierungsserver für DPoP-Proof-JWTs unterstützt.

dpop_signing_alg_values_supported: Ein JSON-Array, das eine Liste der JWS alg-Werte (aus dem [IANA.JOSE.ALGS]-Register) enthält, die vom Autorisierungsserver für DPoP-Proof-JWTs unterstützt werden.

5.2. Metadaten zur Client-Registrierung

Das Protokoll zur dynamischen Client-Registrierung [RFC7591] definiert eine API für Clients, um OAuth 2.0-Client-Metadaten dynamisch beim Autorisierungsserver zu registrieren. Die durch [RFC7591] definierten Metadaten und Registrierungserweiterungen dazu schlagen auch ein allgemeines Client-Datenmodell vor, das für Implementierungen von Autorisierungsservern nützlich ist, auch wenn das Protokoll zur dynamischen Client-Registrierung nicht verwendet wird. Typischerweise haben solche Implementierungen eine Benutzeroberfläche zur Verwaltung der Client-Konfiguration.

Dieses Dokument führt den folgenden Client-Registrierungs-Metadatenparameter [RFC7591] ein, um anzuzeigen, dass der Client bei der Anforderung von Token vom Autorisierungsserver immer DPoP verwenden wird:

dpop_bound_access_tokens: Ein boolescher Wert, der angibt, ob der Client immer DPoP für Token-Anforderungen verwenden wird. Bei Auslassung ist der Standardwert false.

Wenn true, MUSS der Autorisierungsserver Token-Anforderungen von diesem Client ablehnen, die keinen DPoP-Header enthalten.