4. Authorization Request (Requête d'autorisation)

4. Authorization Request (Requête d'autorisation)

Le client utilise la valeur request_uri renvoyée par le serveur d'autorisation pour construire une requête d'autorisation comme défini dans [RFC9101]. L'exemple suivant montre le client demandant à l'agent utilisateur d'effectuer la requête HTTP suivante (affichage uniquement) :

GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
 %3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1
Host: as.example.com

Comme certaines parties du contenu, par ex. la valeur de code_challenge, sont propres à une requête donnée, le client NE DOIT utiliser une valeur request_uri qu'une seule fois. Les serveurs d'autorisation DEVRAIENT traiter les request_uri comme à usage unique mais PEUVENT autoriser des doublons dus au rechargement de l'agent utilisateur. Un request_uri expiré DOIT être rejeté comme invalide.

Le serveur d'autorisation DOIT valider les requêtes d'autorisation issues d'une requête poussée comme toute autre requête d'autorisation. Il PEUT omettre des étapes déjà effectuées lors du push s'il peut vérifier qu'il s'agissait d'une requête poussée et que la requête ou la politique n'a pas été modifiée d'une manière affectant le résultat des étapes omises.

La politique du serveur d'autorisation PEUT imposer globalement ou par client que PAR soit le seul moyen de transmettre les données de requête d'autorisation. Dans ce cas, le serveur refuse, avec le code invalid_request, toute requête vers le point de terminaison d'autorisation sans paramètre request_uri dont la valeur provient du point de terminaison PAR.

Remarque : le serveur et les clients PEUVENT utiliser les métadonnées des sections 5 et 6 pour signaler le comportement souhaité.