1. Introduction (Introduction)

1. Introduction (Introduction)

Ce document définit le point de terminaison pushed authorization request (PAR), qui permet à un client OAuth [RFC6749] de pousser directement la charge utile d'une requête d'autorisation vers le serveur d'autorisation. Une valeur d'URI de requête est reçue en échange ; elle sert de référence aux données de charge utile de la requête d'autorisation lors d'un appel ultérieur au point de terminaison d'autorisation via l'agent utilisateur.

Dans OAuth [RFC6749], les paramètres de requête d'autorisation sont en général envoyés comme paramètres de requête URI par redirection dans l'agent utilisateur. C'est simple mais pose aussi des difficultés :

• Il n'y a pas de protection cryptographique d'intégrité ni d'authenticité. Un attaquant pourrait par exemple modifier la portée d'accès demandée ou substituer le contexte d'une transaction de paiement en changeant les valeurs de scope. Bien que le protocole offre des moyens pour que les clients ou les utilisateurs détectent certains changements, empêcher les modifications tôt dans le processus est une solution plus robuste.

• Il n'existe pas de mécanisme assurant la confidentialité des paramètres de requête. Bien que HTTPS soit requis pour le point de terminaison d'autorisation, les données de requête transitent en clair par l'agent utilisateur, et les données de chaîne de requête peuvent fuiter involontairement vers les journaux du serveur Web et vers d'autres sites via le référent. L'impact d'une telle fuite peut être important si des informations personnelles identifiables ou d'autres données réglementées sont envoyées dans la requête d'autorisation (ce qui peut être le cas dans l'identité, l'open banking et des scénarios similaires).

• Les URL de requête d'autorisation peuvent devenir assez grandes, notamment lorsque des données d'autorisation fines sont nécessaires, ce qui peut provoquer des erreurs de traitement.

JWT-Secured Authorization Request (JAR) [RFC9101] apporte des réponses aux défis de sécurité en permettant aux clients OAuth d'envelopper les paramètres de requête d'autorisation dans un Request Object, qui est un JSON Web Token (JWT) [RFC7519] signé et éventuellement chiffré. Pour gérer les restrictions de taille, JAR introduit le paramètre request_uri, qui permet d'envoyer une référence à un Request Object plutôt que l'objet lui-même.

Ce document complète JAR en fournissant un moyen interopérable de pousser directement la charge utile d'une requête d'autorisation vers le serveur d'autorisation en échange d'une valeur request_uri utilisable sur le serveur d'autorisation lors d'une requête d'autorisation ultérieure.

PAR renforce la sécurité d'OAuth en offrant aux clients un moyen simple d'obtenir une requête d'autorisation confidentielle et protégée en intégrité. Les clients exigeant un niveau de sécurité encore plus élevé, notamment une non-répudiation confirmée cryptographiquement, peuvent utiliser des Request Objects basés sur JWT tels que définis par [RFC9101] conjointement avec PAR.

PAR permet au serveur d'autorisation d'authentifier le client avant toute interaction avec l'utilisateur. La confiance accrue dans l'identité du client pendant le processus d'autorisation permet au serveur d'autorisation de refuser beaucoup plus tôt les requêtes illégitimes, ce qui peut empêcher les tentatives d'usurpation de client ou autrement la falsification ou l'abus d'une requête d'autorisation.

Notez que des requêtes HTTP POST vers le point de terminaison d'autorisation via l'agent utilisateur, comme décrit dans la section 3.1 de [RFC6749] et la section 3.1.2.1 de [OIDC], pourraient aussi être utilisées pour gérer les limitations de taille décrites ci-dessus. Cependant, ce n'est qu'optionnel selon [RFC6749] et, même lorsque c'est pris en charge, c'est viable pour les applications Web classiques mais prohibitif pour les applications mobiles installées. Comme décrit dans [RFC8252], ces applications utilisent des API spécifiques à la plateforme pour ouvrir l'URI de requête d'autorisation dans le navigateur système. Lorsqu'une application mobile lance un navigateur, la requête initiale résultante est limitée à la méthode GET. Utiliser POST pour la requête d'autorisation exigerait que l'application dirige d'abord le navigateur vers un URI contrôlé par l'application via GET tout en transmettant d'une manière ou d'une autre la charge utile volumineuse, puis que la réponse contienne le contenu et le script pour initier un POST de formulaire inter-site vers le serveur d'autorisation. PAR est plus simple à utiliser et présente des avantages de sécurité supplémentaires, comme indiqué ci-dessus.

Voir 1.1. Introductory Example (Exemple introductif) et 1.2. Conventions and Terminology (Conventions et terminologie).