5. DPoP Access Token Request

Pour demander un jeton d'accès lié à une clé publique à l'aide de DPoP, le client DOIT fournir un JWT de preuve DPoP valide dans un en-tête DPoP lors d'une demande de jeton d'accès au point de terminaison de jeton du serveur d'autorisation. Cela s'applique à toutes les demandes de jeton d'accès, quel que soit le type d'autorisation (par exemple, les types d'autorisation courants authorization_code et refresh_token, ainsi que les types d'autorisation d'extension comme l'autorisation JWT [RFC7523]). La requête HTTP de la Figure 5 illustre une telle demande de jeton d'accès utilisant l'autorisation par code d'autorisation et incluant un JWT de preuve DPoP dans l'en-tête DPoP. L'exemple utilise "\" pour le retour à la ligne, conformément à la [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-

 Figure 5: Demande de jeton demandant un jeton contraint par émetteur DPoP à l'aide d'un code d'autorisation

Le champ d'en-tête HTTP DPoP DOIT contenir un JWT de preuve DPoP valide. Si la preuve DPoP n'est pas valide, le serveur d'autorisation renvoie une réponse d'erreur comme décrit dans la section 5.2 de la [RFC6749], avec une valeur de paramètre error de invalid_dpop_proof.

Après avoir vérifié la validité de la preuve DPoP, le serveur d'autorisation associe le jeton d'accès émis à la clé publique de la preuve DPoP pour contraindre l'émetteur du jeton d'accès. Cela peut se faire comme décrit dans la section 6. La réponse de jeton d'accès DOIT inclure un token_type de DPoP pour indiquer au client que le jeton d'accès a été lié à la clé DPoP et peut être utilisé comme décrit dans la section 7.1. L'exemple de réponse de la Figure 6 illustre une telle réponse.

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"
}

                   Figure 6: Réponse de jeton d'accès

L'exemple de réponse de la Figure 6 comprend un jeton d'actualisation que le client peut utiliser pour obtenir un nouveau jeton d'accès lorsque l'ancien expire. L'actualisation d'un jeton d'accès est une demande de jeton au point de terminaison de jeton du serveur d'autorisation à l'aide du type d'autorisation refresh_token. Comme pour toutes les demandes de jeton d'accès, le client fait de cette demande une demande DPoP en incluant une preuve DPoP, comme indiqué dans la Figure 7. L'exemple utilise "\" pour le retour à la ligne, conformément à la [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

 Figure 7: Demande de jeton demandant un jeton lié à DPoP à l'aide d'un jeton d'actualisation

Lorsqu'un serveur d'autorisation prenant en charge DPoP émet un jeton d'actualisation à un client public qui présente une preuve DPoP valide au point de terminaison de jeton, le jeton d'actualisation DOIT être lié à la clé publique correspondante. Lorsque le jeton d'actualisation est ensuite utilisé pour obtenir un nouveau jeton d'accès, cette liaison DOIT être validée. Un tel client DOIT donc présenter une preuve DPoP avec la même clé que celle utilisée pour obtenir le jeton d'actualisation chaque fois que ce jeton d'actualisation est utilisé pour obtenir un nouveau jeton d'accès. Les détails de la mise en œuvre de la liaison du jeton d'actualisation sont à la discrétion du serveur d'autorisation. Il n'y a pas de considérations d'interopérabilité pour les détails spécifiques de la liaison car le serveur d'autorisation génère et valide le jeton d'actualisation.

Le serveur d'autorisation PEUT choisir d'émettre un jeton d'accès non lié à DPoP en utilisant la valeur Bearer ([RFC6750]) dans le paramètre token_type de la réponse de jeton d'accès. Pour les clients publics obtenant également un jeton d'actualisation, cela a pour effet de lier uniquement le jeton d'actualisation à DPoP, ce qui peut encore améliorer la posture de sécurité même si les ressources protégées ne sont pas mises à jour pour prendre en charge DPoP.

Si la réponse de jeton d'accès contient une valeur token_type autre que DPoP, le client n'obtient pas la protection de jeton d'accès offerte par DPoP. Si cette protection est importante pour la sécurité de l'application, le client DOIT ignorer la réponse. Sinon, le client peut continuer comme avec une interaction OAuth normale.

Les jetons d'actualisation émis aux clients confidentiels (c'est-à-dire les clients qui ont établi des identifiants d'authentification avec le serveur d'autorisation) NE SONT PAS liés à la clé publique de la preuve DPoP car ils sont déjà protégés par l'expéditeur via un mécanisme existant différent. Le cadre d'autorisation OAuth 2.0 [RFC6749] exige déjà que le serveur d'autorisation lie les jetons d'actualisation au client qui les a émis, et les clients confidentiels s'authentifient auprès du serveur d'autorisation lorsqu'ils présentent le jeton d'actualisation. Par conséquent, ces jetons d'actualisation sont contraints par l'expéditeur grâce à l'identifiant du client et à l'exigence d'authentification associée. Ce mécanisme de contrainte par l'expéditeur existant est plus flexible qu'une liaison directe à une clé publique spécifique (il permet par exemple la rotation des identifiants du client sans invalider les jetons d'actualisation).

5.1. Métadonnées du serveur d'autorisation

Ce document introduit les paramètres de métadonnées du serveur d'autorisation [RFC8414] suivants pour signaler la prise en charge générale de DPoP et les valeurs alg JWS spécifiques prises en charge par le serveur d'autorisation pour les JWT de preuve DPoP.

dpop_signing_alg_values_supported : Un tableau JSON contenant une liste des valeurs alg JWS (du registre [IANA.JOSE.ALGS]) prises en charge par le serveur d'autorisation pour les JWT de preuve DPoP.

5.2. Métadonnées d'enregistrement du client

Le protocole d'enregistrement dynamique de client [RFC7591] définit une API permettant aux clients d'enregistrer dynamiquement des métadonnées OAuth 2.0 auprès des serveurs d'autorisation. Les métadonnées définies par la [RFC7591] et les extensions d'enregistrement à celles-ci suggèrent également un modèle de données client général utile pour les implémentations de serveurs d'autorisation, même lorsque le protocole d'enregistrement dynamique de client n'est pas utilisé. Généralement, de telles implémentations disposent d'une interface utilisateur pour gérer la configuration des clients.

Ce document introduit le paramètre de métadonnées d'enregistrement de client [RFC7591] suivant pour indiquer que le client utilisera toujours DPoP lors de la demande de jetons au serveur d'autorisation :

dpop_bound_access_tokens : Valeur booléenne spécifiant si le client utilisera toujours DPoP pour les demandes de jeton. En cas d'omission, la valeur par défaut est false.

Si true, le serveur d'autorisation DOIT rejeter les demandes de jeton de ce client qui ne contiennent pas l'en-tête DPoP.