Cloudflare a activé le 22 août 2026 le consentement OAuth à granularité fine pour Wrangler et pour le serveur MCP de son API. Jusque-là, autoriser l’outil revenait à accepter en bloc toutes les permissions demandées ; il devient possible de n’en accorder qu’une partie, et donc de rapprocher l’outillage en ligne de commande du principe de moindre privilège.
Ce que change le consentement optionnel
Le modèle OAuth classique fonctionnait en tout ou rien : l’écran de consentement listait les scopes réclamés par le client, sans autre choix que tout accepter ou tout refuser. La nouveauté introduit une distinction entre scopes requis, pré-cochés et non désactivables, et scopes optionnels, que la personne peut refuser avant de valider. Le jeton délivré ne contient alors que les permissions réellement accordées.
Concrètement, la boîte de dialogue d’autorisation présente désormais un bouton « Edit permissions » qui ouvre la liste des scopes optionnels. Décocher un scope réduit d’autant la surface d’accès du jeton. Si une commande a plus tard besoin d’une permission refusée, il suffit de ré-autoriser le client pour l’ajouter.
| Scope demandé | Classement | Ce qu’il autorise |
|---|---|---|
user-details.read | Requis | Lecture du profil du compte |
zone.read | Requis | Lecture de la configuration des zones |
workers-scripts.write | Optionnel | Déploiement de Workers |
workers-kv-storage.write | Optionnel | Écriture dans les espaces KV |
Point de vigilance : les applications qui consomment ces jetons doivent gérer les octrois partiels. Après l’échange, il faut vérifier les scopes réellement présents dans le jeton plutôt que de supposer que tout ce qui a été demandé a été accordé.
Comment un scope devient optionnel
Le classement se fait côté développeur du client OAuth, dans le tableau de bord Cloudflare : chaque scope configuré peut être marqué requis ou optionnel. Par défaut, tous restent requis, ce qui préserve le comportement existant. Le calcul requis/optionnel ne porte que sur les scopes effectivement demandés lors d’un flux d’autorisation donné, pas sur l’ensemble configuré ; si aucun scope optionnel n’est réclamé, l’écran de consentement ne change pas. La fonction est disponible à partir de Wrangler 4.116.
# Ré-autoriser Wrangler en n'accordant qu'un sous-ensemble de scopes
npx wrangler logout
npx wrangler login
# → l'écran de consentement propose « Edit permissions »
# décochez les scopes optionnels dont le workflow n'a pas besoin
# Si une commande échoue faute de permission, ré-autoriser pour ajouter le scope
npx wrangler login # cochez cette fois le scope manquantPourquoi le sujet touche les agents et le MCP
L’intérêt dépasse le cas d’un développeur qui lance wrangler deploy. Cloudflare cite explicitement les serveurs MCP, qui exposent des outils à des agents. Un tel serveur tend à réclamer un large éventail de permissions, puisqu’en théorie un agent pourrait toutes les employer ; en pratique, peu d’utilisateurs souhaitent qu’un agent dispose d’un accès aussi étendu. Les scopes optionnels laissent accorder à l’agent le strict nécessaire, sans que l’éditeur du serveur ait à bâtir sa propre interface de sélection de permissions.
Un jeton qui ne peut écrire que sur les Workers ne peut ni purger un cache ni lire une zone DNS.
Cette logique rejoint un mouvement de fond côté délégation d’accès aux agents : réduire le rayon d’action d’un jeton compromis, et rendre lisible, au moment du consentement, ce qu’un outil automatisé pourra faire. Le sujet prolonge les questions déjà posées par la montée en puissance du protocole MCP.
Ce qu’il faut retenir
Le changement est discret mais structurant : il fait passer l’autorisation de Wrangler et du serveur MCP d’un modèle binaire à un octroi ajustable. Pour les équipes, c’est l’occasion de revoir les jetons distribués aux intégrations et aux agents, et de n’accorder que ce qu’un workflow exige réellement. Le coût d’adoption est nul côté utilisateur ; l’effort porte sur les éditeurs de clients, qui doivent classer leurs scopes et gérer proprement les octrois partiels.
La bonne valeur par défaut pour un jeton d’agent, c’est le plus petit ensemble de permissions qui laisse la tâche aboutir, quitte à ré-autoriser quand le besoin change. Je vois trop de jetons d’automatisation taillés « au cas où », avec des droits d’écriture dont personne ne se sert et qui ne servent qu’à agrandir la cible en cas de fuite. Rendre le refus de scope trivial au moment du consentement est exactement le genre de détail qui fait basculer une bonne pratique du discours à l’usage réel — Simon Janvier
