Aller au contenu principal

2.1. Request (Requête)

2.1. Request (Requête)

Le client envoie directement au point de terminaison PAR les paramètres qui composent une requête d'autorisation. Un ensemble typique peut inclure client_id, response_type, redirect_uri, scope, state, code_challenge et code_challenge_method comme dans l'exemple ci-dessous. Toutefois, la requête d'autorisation poussée peut être composée de tout paramètre utilisable au point de terminaison d'autorisation, y compris ceux définis dans [RFC6749] et toutes les extensions applicables. Le paramètre de requête d'autorisation request_uri est une exception et NE DOIT PAS être fourni.

La requête inclut également, selon le client, tout paramètre supplémentaire nécessaire à l'authentification client (par ex. client_secret ou client_assertion et client_assertion_type). Ces paramètres sont définis et enregistrés pour le point de terminaison de jeton mais ne concernent que l'authentification client. Lorsqu'ils sont présents dans une requête d'autorisation poussée, ils ne servent qu'à l'authentification client et ne concernent pas la requête d'autorisation elle-même. Tout paramètre du point de terminaison de jeton sans lien avec l'authentification client n'a pas de sens défini pour une requête d'autorisation poussée. Le paramètre client_id a la même sémantique pour les requêtes d'autorisation et les requêtes vers le point de terminaison de jeton ; comme paramètre d'autorisation obligatoire, il est également obligatoire dans une requête d'autorisation poussée.

Le client construit le corps du message d'une requête HTTP POST avec des paramètres au format x-www-form-urlencoded et encodage UTF-8, comme décrit dans l'annexe B de [RFC6749]. Le cas échéant, le client ajoute ses informations d'identification d'authentification à l'en-tête ou au corps selon les mêmes règles que pour les requêtes au point de terminaison de jeton.

Illustration (sauts de ligne dans le corps pour l'affichage uniquement) :

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
&code_challenge_method=S256&scope=account-information
&client_assertion_type=
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi
OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc
2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh
TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se
f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K
dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W
yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE
RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6
GQ

Le serveur d'autorisation DOIT traiter la requête comme suit :

  1. Authentifier le client comme au point de terminaison de jeton (section 2.3 de [RFC6749]).

  2. Rejeter la requête si le paramètre de requête d'autorisation request_uri est fourni.

  3. Valider la requête poussée comme une requête d'autorisation envoyée au point de terminaison d'autorisation. Par exemple, vérifier que l'URI de redirection correspond à l'un des URI configurés pour le client et que le client est autorisé pour la portée demandée. Cette validation permet de refuser tôt les requêtes non autorisées ou frauduleuses. Le serveur d'autorisation PEUT omettre des étapes qu'il ne peut pas effectuer lors du traitement de la requête poussée ; toutefois, ces vérifications DOIVENT alors être effectuées lors du traitement de la requête d'autorisation au point de terminaison d'autorisation.

Le serveur d'autorisation PEUT permettre aux clients disposant d'informations d'authentification d'établir des URI de redirection propres à chaque requête d'autorisation à chaque requête poussée. Comme détaillé à la section 2.4, cela est possible car, contrairement à [RFC6749], la présente spécification permet d'authentifier les clients et de valider les requêtes avant l'exécution effective de la requête d'autorisation.