1. Introduction
1. Introduction
La demande d'autorisation OAuth 2.0 [RFC6749] utilise la sérialisation des paramètres de requête et est généralement envoyée via des agents utilisateur tels que les navigateurs Web.
Par exemple, les paramètres response_type, client_id, state et redirect_uri sont encodés dans l'URI de la requête :
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
Bien que facile à mettre en œuvre, l'encodage dans l'URI ne permet pas d'utiliser la sécurité au niveau application pour assurer confidentialité et intégrité. TLS protège la communication entre le client et l'agent utilisateur ainsi qu'entre l'agent utilisateur et le serveur d'autorisation, mais les sessions TLS se terminent dans l'agent utilisateur. De plus, une session TLS peut être terminée prématurément sur un équipement intermédiaire (tel qu'un répartiteur de charge).
Par conséquent, la demande d'autorisation de [RFC6749] présente les lacunes suivantes :
(a) la communication via les agents utilisateur n'est pas protégée en intégrité, et les paramètres peuvent être altérés ;
(b) la source de la communication n'est pas authentifiée ;
(c) la communication via les agents utilisateur peut être surveillée.
En raison de ces faiblesses inhérentes, plusieurs attaques contre le protocole ont été identifiées, comme la réécriture de l'URI de redirection.
L'utilisation de la sécurité au niveau application atténue ces problèmes.
Elle permet aussi de préparer les requêtes par un tiers de confiance afin qu'une application cliente ne puisse pas demander plus d'autorisations que convenu.
De plus, transmettre la requête par référence réduit la surcharge sur le fil.
L'encodage JWT [RFC7519] a été choisi parce que : (1) il est étroitement lié à JSON, utilisé comme format de réponse OAuth ; (2) il est convivial pour les développeurs grâce à sa nature textuelle ; (3) il est relativement compact par rapport à XML ; (4) il est au statut Proposed Standard avec des méthodes de signature et de chiffrement associées [RFC7515] [RFC7516] ; (5) JWS et JWE sont relativement plus simples que XML Signature et Encryption.
Les paramètres request et request_uri sont introduits comme paramètres supplémentaires de demande d'autorisation pour les flux OAuth 2.0 [RFC6749]. Le paramètre request est un JWT [RFC7519] dont l'ensemble de revendications contient les paramètres de demande d'autorisation encodés en JSON. Contrairement à la RFC 7519, les éléments de l'ensemble sont des paramètres OAuth encodés [IANA.OAuth.Parameters], complétés seulement par quelques revendications JWT gérées par l'IANA [IANA.JWT.Claims], notamment iss et aud. Le JWT dans request est protégé en intégrité et authentifié en source à l'aide de JWS.
Le JWT [RFC7519] peut être passé à l'endpoint d'autorisation par référence, auquel cas le paramètre request_uri remplace request.
Utiliser JWT [RFC7519] comme encodage de requête présente plusieurs avantages : (a) protection d'intégrité ; (b) authentification de la source ; (c) protection de la confidentialité ; (d) minimisation de la collecte (signature par un tiers attestant la conformité à une politique).
Les cas d'utilisation de la requête par référence incluent : 1) réduire la taille transmise lorsque la cryptographie à clé publique augmente la taille ; 2) éviter la cryptographie au niveau application côté client lorsque le serveur d'autorisation fournit un endpoint en communication directe TLS avec le client.
Cette capacité est utilisée par OpenID Connect [OpenID.Core].