Cloudflare annonce la levée complète des restrictions OAuth, les développeurs d'AI Agent n'ont plus besoin de validation manuelle.

Cloudflare annonce l'ouverture de son OAuth auto-géré à tous les développeurs, supprimant l'obligation d'un examen manuel pour l'intégration. Derrière cette décision se trouvent la croissance explosive des outils d'agents IA en matière de délégation d'autorisations, ainsi qu'un remplacement de moteur sous-jacent impliquant la migration de 130 millions de lignes de données.
(Rappel précédent : Données Cloudflare : 34% du trafic sur Internet n'est pas humain, les robots d'IA grandissent 8 fois plus vite)
(Contexte complémentaire : UBS et TD Cowen relèvent le prix cible d'Arm à 475 $ le même jour, citant les revenus futurs des CPU conçus en interne)

Table des matières

Toggle

• Pourquoi maintenant ?
• Un remplacement de moteur sous-jacent impliquant 130 millions de lignes de données
• Problème de cascade d'invalidation des refresh tokens pour les clients MCP

Cloudflare, qui gère 20 % du trafic mondial, a pris une décision clé cette semaine : permettre à tous les développeurs de créer et gérer leurs propres clients OAuth sans nécessiter d'examen manuel individuel. La force motrice derrière cette décision est la demande massive des outils d'agents IA en matière d'« autorisation déléguée ». Lorsque les modèles d'IA doivent accéder aux ressources Cloudflare pour le compte d'utilisateurs, ils ne pouvaient auparavant s'appuyer que sur des jetons API, une méthode difficile à gérer et inadaptée aux workflows d'agents nécessitant des niveaux de consentement clairs.

Pourquoi maintenant ?

Cloudflare n'est pas un novice en matière d'OAuth. Lorsque les développeurs utilisaient l'outil CLI Wrangler ou se connectaient à des services partenaires comme PlanetScale, l'OAuth fonctionnait déjà en arrière-plan en silence. Mais ces intégrations étaient en mode fermé « avec examen manuel », et les développeurs tiers ne pouvaient tout simplement pas créer leurs propres flux OAuth standard.

Dans un billet de blog officiel, Cloudflare indique que l'année dernière, ils ont progressivement introduit des partenaires précoces, améliorant continuellement le mécanisme de consentement, le processus de révocation et le modèle de sécurité. Mais à mesure que la plateforme de développeurs s'élargit et que la demande d'accès délégué par les outils d'agents IA augmente rapidement, « ouvrir l'OAuth à tous les utilisateurs » est devenu une condition nécessaire, et non une option, pour le succès de la plateforme.

L'OAuth auto-géré permet aux développeurs d'offrir un flux d'autorisation standard : l'utilisateur accorde directement un accès limité à une portée, l'application sait ce qu'elle est autorisée à faire, et l'utilisateur peut révoquer l'accès à tout moment. Pour la création d'intégrations SaaS, de plateformes de développeurs internes et de divers outils d'agents IA, cela constitue une infrastructure plus propre que les jetons API.

Un remplacement de moteur sous-jacent impliquant 130 millions de lignes de données

Cependant, pour ouvrir l'OAuth à grande échelle, Cloudflare a d'abord dû résoudre un problème d'ingénierie : le moteur d'autorisation sous-jacent Hydra n'était plus capable de supporter la charge.

Hydra est un moteur OAuth open source que Cloudflare a déployé il y a plusieurs années pour soutenir l'infrastructure OAuth de la plateforme. Il fonctionnait de manière stable lorsque l'utilisation était limitée, mais avec l'expansion de la plateforme de développeurs et la généralisation des workflows d'IA, les goulets d'étranglement de performance et les limitations fonctionnelles de l'Hydra original sont devenus de plus en plus évidents.

Le plan de mise à niveau s'est déroulé en deux phases. La première phase était la mise à niveau vers Hydra 1.X. Les ingénieurs ont découvert que même une migration de version mineure impliquait des changements de structure de base de données non négligeables. Ils ont réécrit les scripts de migration SQL, adoptant des techniques comme CREATE INDEX CONCURRENTLY qui ne verrouillent pas les écritures, et ont personnalisé la version de construction d'Hydra pour remplacer la requête SELECT * par des colonnes explicitement spécifiées, réduisant ainsi les transferts de données inutiles.

La deuxième phase était le déploiement bleu-vert (blue-green deployment) d'Hydra 2.X. Le déploiement bleu-vert signifie que les deux systèmes, ancien et nouveau, fonctionnent simultanément, et le trafic est progressivement basculé après confirmation de la stabilité du nouveau système, permettant à tout moment un retour en arrière immédiat, réduisant ainsi le risque d'interruption du système à presque zéro. Cloudflare indique que dans ce cadre, ils ont mis en place un système de file d'attente basé sur Cloudflare Queues, permettant de synchroniser correctement les événements de révocation entre les anciens et les nouveaux systèmes.

L'ampleur de la migration de la base de données était considérable : 132,5 millions de lignes de données ont été mises à jour, 114,7 millions de nouvelles lignes insérées, générant 136,97 Go de données temporaires.

Problème de cascade d'invalidation des refresh tokens pour les clients MCP

Après le basculement bleu-vert, les données de surveillance ont révélé un signal inattendu : une augmentation du taux d'erreur des refresh tokens.

En recherchant la cause, il s'est avéré que la nouvelle version d'Hydra avait adopté un mécanisme d'invalidation plus strict concernant la réutilisation des refresh tokens : dès qu'une réutilisation du même refresh token est détectée, l'ensemble des identifiants d'accès (access token et refresh token) sont révoqués.

Cela a posé problème aux clients Wrangler et MCP, car ces outils, dans des situations de réseau instable ou de requêtes concurrentes, pouvaient naturellement déclencher une réutilisation des refresh tokens.

La solution a été d'ajouter un « mécanisme de fusion des refresh tokens » dans le Worker qui achemine le trafic OAuth : lorsque plusieurs demandes de mise à jour pour le même token arrivent simultanément, le système les fusionne en une seule requête, évitant ainsi de déclencher la logique d'invalidation en cascade. Ce correctif a ramené le comportement d'intégration des clients MCP à la normale.

Cette anecdote révèle également une réalité : le modèle de comportement d'autorisation des outils d'agents IA diffère structurellement des flux OAuth traditionnels opérés manuellement. Les outils d'agents peuvent générer un grand nombre de demandes concurrentes de mise à jour de tokens en peu de temps, alors que les implémentations OAuth traditionnelles ne sont pas conçues pour ce type de scénario d'utilisation.

Après la mise à niveau, l'amélioration des indicateurs de performance a été significative. La latence P95 de l'API est passée de 185 ms à 101 ms, soit une réduction de 45 % ; l'occupation mémoire résidente est passée de 888 Mo à 763 Mo, soit une réduction de 14 % ; l'allocation mémoire Go heap est passée de 449 Mo à 271 Mo, soit une réduction de 40 % ; le nombre de goroutines est passé de 4 015 à 3 076, soit une réduction de 23 % ; l'utilisation du CPU est passée de 1,07 cœur à 0,67 cœur, soit une économie de 37 %.

Cloudflare indique que l'ouverture de l'OAuth auto-géré permet aux développeurs de construire des intégrations avec un consentement utilisateur plus transparent et une révocation plus facile, ce qui est particulièrement important pour la santé de l'écosystème des outils d'agents IA. Lorsque les modèles d'IA opèrent des services pour le compte d'humains, « ce que cet agent est autorisé à faire » et « comment révoquer son accès » sont des questions inévitables dans le cadre de la confiance.