1. Introduction
1. Introduction
Plusieurs années de déploiement et d'expérience d'implémentation du cadre d'autorisation OAuth 2.0 [RFC6749] ont révélé un besoin, dans certaines circonstances (par exemple lorsqu'un serveur d'autorisation dessert un nombre important de ressources diverses), pour que le client signale explicitement au serveur d'autorisation où il entend utiliser le jeton d'accès (access token) qu'il demande.
Connaître la ressource protégée (également appelée serveur de ressources, application, API, etc.) qui traitera le jeton d'accès permet au serveur d'autorisation de construire le jeton comme nécessaire pour cette entité. Chiffrer correctement le jeton (ou son contenu) pour une ressource particulière exige par exemple de savoir quelle ressource recevra et déchiffrera le jeton. De plus, les ressources ont souvent des exigences différentes concernant les données contenues dans le jeton (ou auxquelles il renvoie), et connaître la ressource où le client entend utiliser le jeton permet au serveur d'autorisation de l'émettre en conséquence.
Une connaissance précise du ou des destinataires prévus du jeton d'accès facilite également l'amélioration des caractéristiques de sécurité du jeton lui-même. Les jetons bearer, actuellement le type de jeton d'accès OAuth le plus courant, permettent à toute partie en possession d'un jeton d'obtenir l'accès aux ressources associées. Pour prévenir les abus, plusieurs hypothèses de sécurité importantes doivent être satisfaites, dont le fait qu'un jeton d'accès ne doit être valide que pour une ressource protégée spécifique et pour une portée (scope) d'accès spécifique. La section 5.2 de [RFC6750] prescrit par exemple d'inclure dans le jeton ses destinataires prévus afin d'empêcher la redirection de jeton. Lorsque le serveur d'autorisation est informé de la ressource qui traitera le jeton d'accès, il peut restreindre l'audience prévue de ce jeton à la ressource donnée de sorte que le jeton ne puisse pas être utilisé avec succès sur d'autres ressources.
La portée OAuth, définie à la section 3.3 de [RFC6749], est parfois surchargée pour transmettre l'emplacement ou l'identité de la ressource protégée ; ce n'est toutefois pas toujours faisable ni souhaitable. La portée concerne en général le type d'accès demandé plutôt que le lieu où cet accès sera utilisé (par exemple « email », « admin:org », « user_photos », « channels:read » et « channels:write » sont un petit échantillon de valeurs de portée en usage qui ne transmettent que le type d'accès et non l'emplacement ou l'identité).
Dans certaines circonstances et pour certains déploiements, un moyen pour le client de signaler au serveur d'autorisation où il entend utiliser le jeton d'accès demandé est important et utile. De nombreuses implémentations et déploiements d'OAuth 2.0 ont déjà employé des paramètres propriétaires à cette fin. À l'avenir, cette spécification vise à fournir une alternative normalisée et interopérable aux approches propriétaires.