Cloudflare a annoncé l’ajout de la personnalisation des portées OAuth, une fonctionnalité qui permet aux propriétaires d’applications OAuth tierces de définir des autorisations obligatoires et facultatives. Ainsi, lors de l’écran de consentement, l’utilisateur peut désélectionner les autorisations facultatives et accorder à l’application un accès plus limité, au lieu de devoir choisir entre accepter toutes les autorisations demandées ou refuser entièrement la demande.
Cette initiative intervient après que les développeurs ont créé des milliers d’applications OAuth tierces sur Cloudflare depuis juin, avec plus d’un million d’opérations d’autorisation enregistrées depuis lors. Ces applications sont utilisées dans des intégrations de logiciels en tant que service, des outils internes, des interfaces en ligne de commande et des agents logiciels.
Du consentement global aux autorisations liées à la tâche
Cloudflare OAuth permettait à l’application de demander un sous-ensemble des portées qui lui avaient été configurées, mais l’utilisateur ne pouvait pas réduire cet ensemble depuis l’écran de consentement lui-même. Si l’application demandait davantage d’autorisations que ce que l’utilisateur jugeait approprié, celui-ci n’avait d’autre choix que d’accorder la demande complète ou de la refuser.
Cloudflare explique que les serveurs MCP représentent un cas d’utilisation évident de ce problème : un serveur MCP peut demander un large ensemble d’autorisations parce que l’agent pourrait théoriquement en avoir besoin de toutes, alors que l’utilisateur ne souhaite pas nécessairement lui accorder ce niveau d’accès. Avant le lancement de la fonctionnalité, le développeur devait créer un écran personnalisé de sélection des portées avant de rediriger l’utilisateur vers le flux de consentement Cloudflare.
Comment fonctionnent les portées facultatives ?
- Le développeur peut définir certaines portées comme obligatoires ou facultatives lors de la configuration d’un client OAuth.
- L’utilisateur peut désélectionner les portées facultatives au sein de l’ensemble des autorisations demandées dans le processus d’autorisation en cours.
- L’expérience par défaut reste inchangée si le client n’active pas les portées facultatives, et l’écran de consentement accorde l’ensemble demandé si aucune portée facultative n’est désélectionnée.
Le point important est que l’évaluation s’effectue selon les portées demandées par l’application dans un flux d’autorisation donné, et non selon toutes les portées configurées sur le client. Si le client comprend user-details.read, workers-scripts.write, workers-kv-storage.write et zone.read, les deux dernières étant facultatives, la demande des quatre portées laisse à l’utilisateur la possibilité de désélectionner uniquement les deux dernières.
En revanche, si le client demande ultérieurement uniquement workers-scripts.write et zone.read, seules ces deux portées seront évaluées au cours de cette opération. Les autres portées n’apparaîtront pas et ne seront pas imposées, puisqu’elles ne faisaient pas partie de la demande actuelle. Cela contribue à maintenir un écran de consentement centré sur la tâche requise, plutôt qu’à afficher toutes les capacités que l’application pourrait demander à l’avenir.
Quels changements pratiques pour les développeurs ?
Lorsque l’utilisateur désélectionne certaines portées facultatives et termine l’autorisation, le jeton d’accès généré contient uniquement les autorisations qu’il a approuvées. Le développeur doit donc vérifier l’ensemble des portées accordées après l’échange du code d’autorisation, au lieu de supposer que l’application a obtenu l’ensemble des portées demandées.
Cela signifie que les applications, en particulier les agents logiciels, doivent gérer correctement l’octroi partiel des autorisations. Demander le niveau minimal d’accès nécessaire et rendre les autorisations supplémentaires facultatives montre également à l’utilisateur que l’application respecte sa décision concernant les limites d’accès.
Extension aux produits Cloudflare
Cloudflare a déclaré qu’au cours des semaines suivantes, elle étendrait les portées des rôles au niveau du compte et de la zone afin de couvrir presque tous ses produits, notamment davantage de rôles pour les jetons d’API, des options d’adhésion au compte et des portées OAuth. Les développeurs peuvent commencer via la documentation Third Party OAuth ou depuis la page des applications OAuth dans le tableau de bord.
L’entreprise a indiqué que la fonctionnalité avait été développée avec l’aide de 1,111 stagiaires, en saluant les contributions de Miller Vargas et de José Enrique Rodriguez. Selon l’article, Vargas étudie l’informatique et les mathématiques à University of Texas - Austin, tandis que Rodriguez étudie l’ingénierie, l’intelligence des données et la cybersécurité à Universidad Panamericana.