Pour une stack PHP connectée à DNS, Workers, WAF ou statistiques Cloudflare, la surface d’accès devient enfin découpable.
Un modèle d’autorisation moins opaque
Jusqu’ici, l’intégration OAuth directe avec les services Cloudflare était réservée à quelques partenaires. Les autres applications reposaient sur des API Tokens. Fonctionnel, mais peu lisible côté délégation: l’application reçoit un jeton, et la granularité réelle de l’accès devient un paramètre d’infrastructure à surveiller en permanence.
Un client OAuth créé depuis le dashboard Cloudflare inverse ce contrat. L’utilisateur passe par un écran de consentement, voit les permissions demandées et peut les retirer depuis son compte. Une application peut ainsi demander l’accès à une opération précise: modifier des enregistrements DNS, déployer des Workers, administrer le WAF ou consulter certaines métriques.
Le point important n’est pas le protocole en lui-même. C’est le périmètre. Un back-office PHP n’a plus à être conçu autour d’un accès large et durable si son besoin est limité à une zone, un déploiement ou une lecture de statistiques.
Ce que les équipes PHP doivent contrôler
La bascule ne rend pas un connecteur sûr par défaut. Elle rend la délégation plus contrôlable. C’est différent.
Pour les applications qui pilotent Cloudflare, il faut surtout isoler les opérations réellement nécessaires et vérifier que le client OAuth ne demande pas un ensemble de permissions supérieur au flux métier. Un module de déploiement n’a pas le même besoin qu’un écran d’administration DNS; un outil de reporting n’a pas à disposer des droits d’écriture d’un outil d’exploitation.
Cloudflare positionne aussi cette ouverture pour les agents IA et le Model Context Protocol (MCP). Le cas d’usage est direct: un agent susceptible de modifier une configuration, de déployer une application ou d’analyser un réseau doit disposer d’autorisations limitées et révocables, pas d’un accès global figé dans une variable d’environnement.
Le coût technique se déplace donc vers la conception des scopes, le suivi des consentements et le comportement applicatif après révocation. Un token stocké n’est plus l’unique primitive. L’état de l’autorisation devient une donnée opérationnelle.
Une migration d’authentification à l’échelle Cloudflare
L’ouverture s’accompagne d’une modernisation de l’infrastructure d’authentification de Cloudflare, fondée sur Ory Hydra. D’après BlogNT, la migration a porté sur plus de 132 millions de lignes mises à jour, près de 115 millions de nouvelles lignes créées et environ 137 Go de données temporaires manipulées.
Cloudflare indique avoir utilisé une stratégie blue-green: une base migrée est préparée avant le basculement progressif du trafic. Pendant cette phase, une file d’attente enregistre les révocations afin qu’une autorisation supprimée ne soit pas restaurée après migration. C’est le détail qui compte: la révocation n’est pas une fonction décorative si elle peut être perdue lors d’un changement de stockage.
Verdict: à utiliser en production pour les intégrations Cloudflare qui peuvent borner précisément leurs permissions. Conserver des API Tokens larges par inertie n’a plus de justification technique évidente.