Cloudflare OAuth pour tous les clients
(blog.cloudflare.com)- Cloudflare permet désormais aux clients de créer eux-mêmes des applications OAuth autogérées, afin d’offrir l’accès à l’API Cloudflare via un flux standard d’autorisation déléguée
- Auparavant, seuls quelques partenaires intégrés manuellement pouvaient utiliser un OAuth tiers, et les développeurs d’intégrations internes devaient s’appuyer sur des jetons d’API, peu adaptés aux flux d’applications déléguées
- Pour une ouverture complète, Cloudflare a amélioré l’écran de consentement, la révocation et l’affichage de la propriété des applications, tout en faisant évoluer progressivement le moteur OAuth Hydra de la version 1.X à la 2.X
- Pendant la mise à niveau, des migrations de schéma, des erreurs de rafraîchissement de jetons, un risque de perte d’événements de révocation et une hausse des 403 sont apparus, traités via la création d’index concurrente, une file de relecture des révocations et une restauration des données
- Après la mise à niveau, le P95 de l’API est passé de 185 ms à 101 ms, soit une baisse de 45 %, et l’utilisation CPU a également diminué de 1,07 cœur à 0,67 cœur, stabilisant ainsi la base d’exploitation d’un OAuth public
Extension de la disponibilité de Cloudflare OAuth
- Cloudflare permet depuis longtemps de créer de l’automatisation, du CI/CD et des intégrations d’infrastructure via ses API de plateforme, et ouvre désormais OAuth autogéré à tous les clients
- Cloudflare OAuth n’est pas une nouveauté en soi : il était déjà utilisé dans des intégrations partenaires comme Wrangler ou PlanetScale
- Mais l’OAuth tiers existant n’était proposé qu’à un petit nombre d’intégrations intégrées manuellement, sans être ouvert à un écosystème développeur plus large
- Les développeurs créant leurs propres intégrations devaient s’appuyer sur des jetons d’API, une approche difficile à gérer et mal adaptée à de nombreux flux d’applications déléguées
- Avec l’OAuth autogéré, les développeurs peuvent proposer un flux OAuth standard dans lequel les clients autorisent eux-mêmes un accès limité à certains scopes
- Principaux cas d’usage : intégrations SaaS, plateformes internes pour développeurs et outils d’agents
- Les utilisateurs bénéficient d’un consentement plus clair, d’une révocation plus simple et d’un meilleur contrôle sur les permissions des applications
Renforcement des bases de sécurité pour l’ouverture générale
- La solution OAuth initiale suffisait pour un petit nombre de partenaires gérés, mais n’était pas assez mature en matière de modèle d’autorisations, d’expérience de consentement et d’atténuation des abus pour une ouverture à tous les clients
- Plus tôt cette année, Cloudflare a amélioré l’expérience de consentement afin d’indiquer plus clairement quelle application demande l’accès et quelles permissions elle obtiendra
- Le tableau de bord a reçu une fonction de révocation permettant aux développeurs de contrôler facilement quelles applications peuvent accéder à leurs données
- Pour réduire les attaques de phishing OAuth, la propriété de l’application a aussi été rendue plus visible
- Ouvrir l’OAuth autogéré à tous les clients nécessitait une mise à niveau du moteur OAuth capable de préserver la stabilité et la sécurité des données tout en minimisant les interruptions pour les utilisateurs
Préparation de la mise à niveau vers Hydra 1.X
- Cloudflare utilise depuis longtemps le moteur OAuth open source Hydra comme moteur interne de Cloudflare OAuth
- Avec la croissance de la plateforme développeur et la multiplication des workflows d’agents, une mise à niveau majeure est devenue nécessaire pour bénéficier de nouvelles fonctionnalités et d’améliorations de performance
- Plutôt qu’une grosse mise à niveau en une seule fois, Cloudflare a choisi une approche séquentielle : passage d’abord à la dernière version 1.X, évaluation des changements de comportement et de performance, puis migration vers la 2.X
- Même la mise à niveau vers 1.X comportait un risque d’impact pour les clients
- La base de données Hydra créait des index en prenant des verrous exclusifs sur des tables critiques
- Des colonnes étaient ajoutées à des tables importantes, tandis que d’autres colonnes étaient déplacées vers de nouvelles tables
- Le SDK de la version d’Hydra alors utilisée exécutait
SELECT *, ce qui pouvait provoquer des problèmes de désérialisation lors des changements de schéma
- Pour éviter tout impact utilisateur, Cloudflare a réécrit les migrations SQL avec des mécanismes comme
CREATE INDEX CONCURRENTLY, et a créé une version personnalisée d’Hydra sélectionnant des colonnes explicites au lieu deSELECT *
Stratégie de mise à niveau vers Hydra 2.X
- La mise à niveau vers 2.X impliquait des changements de schéma trop importants pour convenir à une mise à niveau sur place, et Cloudflare a donc choisi une stratégie blue-green
- Il ne suffisait pas de simplement basculer vers la nouvelle version
- La mise à niveau et la migration demandaient plusieurs heures
- Pendant ce temps, le système devait continuer à fonctionner correctement
- Une première option blue-green consistait à bloquer les écritures en base pour empêcher les nouvelles autorisations
- Aucune nouvelle écriture n’aurait été perdue pendant la transition
- Les utilisateurs sans identifiants déjà valides n’auraient pas pu utiliser les applications OAuth existantes
- Les utilisateurs n’auraient pas pu révoquer l’accès d’une application pendant la mise à niveau
- La stratégie finale a consisté à maintenir les écritures en base tout en acceptant une perte potentielle d’une partie des écritures, avec des mesures pour réduire ce risque
- Pour réduire les écritures de nouveaux jetons, la durée d’expiration des jetons a été étendue à plusieurs heures
- Les applications ayant reçu des jetons avant la mise à niveau pouvaient continuer à fonctionner sans avoir à les rafraîchir
- La perte d’événements de révocation a été évitée grâce à un système de file reposant sur Cloudflare Queues
- Lorsqu’un événement de révocation survient, l’information est enregistrée dans la file
- Après le basculement vers la base de données de la version green, la file est vidée pour rejouer les révocations survenues pendant la fenêtre de mise à niveau
- En cas d’échec de ce traitement, l’accès d’applications révoquées par les utilisateurs aurait pu être restauré involontairement
Mise à niveau 1.X et problème de rafraîchissement des jetons
- La première mise à niveau vers la dernière version 1.X s’est déroulée sans problème majeur du point de vue opérationnel
- Les migrations de base de données personnalisées se sont exécutées plus vite que prévu et n’ont eu aucun impact utilisateur
- Un basculement franc a été nécessaire, car l’ancienne version ne pouvait pas introspecter les jetons créés par la nouvelle version
- Après le basculement, une hausse d’erreurs sur les refresh tokens, auparavant invisibles, est apparue
- Elle était due à un comportement plus strict de la nouvelle version en matière d’invalidation de refresh
- Lorsqu’un refresh token est réutilisé, Hydra invalide toute la chaîne des access tokens et refresh tokens
- Les clients Wrangler et MCP générant beaucoup de requêtes, une seule réutilisation de refresh token pouvait invalider toute la session
- Cloudflare a ajouté un comportement de coalescence des refresh tokens au Worker chargé de router le trafic OAuth vers la bonne destination
- Les requêtes de refresh token sont brièvement mises en cache avant d’atteindre Hydra
- Lorsqu’une nouvelle tentative est détectée, le système répond en court-circuitant la requête sans invalider le jeton
- Hydra 2.X inclut un
refresh token grace periodconfigurable qui autorise les nouvelles tentatives de refresh pendant un certain temps sans invalider toute la chaîne
Transition vers la 2.X et processus de reprise
- Cloudflare ne pouvant pas se permettre plusieurs heures d’interruption à fort impact utilisateur, l’entreprise a mis en œuvre une mise à niveau blue-green
- En pratique, la transition a demandé davantage qu’une simple copie de la base et le déploiement du nouveau Hydra
- Activation de la file capturant la relecture des révocations
- Copie de la base de données et restauration vers la nouvelle cible
- Nettoyage des données existantes qui violaient les contraintes de la nouvelle version
- Basculement simultané du service Hydra et de deux systèmes internes critiques
- Supervision et validation après le basculement
- La fenêtre de mise à niveau a été choisie au moment où Hydra recevait le moins de requêtes par seconde afin de minimiser la perte d’écritures de jetons
- En production, la migration s’est bien déroulée sur la nouvelle base de données, hors quelques ajustements de timeouts, et le temps d’exécution pur a été d’environ 3 heures
- Juste après le basculement du trafic, un processus de nettoyage des données du service d’autorisation a supprimé excessivement des données de policy OAuth
- Ce service dépend de l’API de session de consentement Hydra
- L’une des migrations Hydra a corrompu certains états de session OAuth valides, marquant des sessions valides comme invalides
- Cette incohérence entre Hydra et le service d’autorisation s’est traduite par une hausse des 403
- Cloudflare a atténué le problème via une restauration des données et a lancé des travaux pour améliorer le comportement d’autorisation OAuth afin de réduire la dépendance à des données de policy statiques
- D’autres petits correctifs liés à certains comportements spécifiques à des clients ont aussi été déployés rapidement
Améliorations de performance après la mise à niveau
- Une fois la mise à niveau des versions d’Hydra terminée, le trafic OAuth est resté stable et les performances comme la fiabilité du système se sont améliorées pour les clients
- La nouvelle base est la même que celle du nouvel API OAuth déjà validé en staging, et elle a permis la sortie de l’OAuth autogéré le 3 juin
- Principales métriques observées pendant la migration de base de données :
- Lignes mises à jour : 132.5M
- Lignes insérées : 114.7M
- Octets temporaires : 136.97GB
- Transactions validées : 22.2k
- Les métriques moyennes de performance d’Hydra se sont globalement améliorées après la mise à niveau
- API P95 : 185 ms → 101 ms, 45 % de baisse
- Mémoire RSS : 888 MB → 763 MB, baisse de 14 %
- Go heap alloc : 449 MB → 271 MB, baisse de 40 %
- Goroutines : 4015 → 3076, baisse de 23 %
- CPU : 1,07 cœur → 0,67 cœur, baisse de 37 %
Comment démarrer
- Tous les clients Cloudflare peuvent désormais créer leurs propres applications OAuth et construire des intégrations sur Cloudflare
- Pour commencer, consultez la documentation ou créez votre première application OAuth depuis la page OAuth apps du tableau de bord
1 commentaires
Commentaires sur Hacker News
Je suis la personne qui a créé Ory Hydra. Ça fait vraiment plaisir de voir cet article de blog et les explications techniques, et je n'aurais jamais imaginé que ce logiciel finirait par protéger des géants de l'internet mondial
C'est rassurant de voir que la version 2.x fonctionne bien à cette échelle, et l'utilisation CPU semble incroyablement faible
En cas de problème, il existe aussi une version commerciale plus rapide. Si vous vous intéressez à l'OAuth auto-hébergé, à l'IAM, aux autorisations ReBAC, aux clés API ou à la sécurité des agents, vous pouvez voir les produits open source et commerciaux sur https://github.com/ory et https://www.ory.com/
J'ai déjà exploité en self-hosting le framework Identity Server pour dotnet, avec plusieurs milliards de requêtes traitées chaque mois, et à cette échelle OAuth et OpenID Connect étaient pratiquement un problème résolu, avec une faible charge de maintenance
C'était un service central pour l'organisation, avec de fortes exigences de conformité, mais l'équipe en charge comptait probablement trois personnes, et ça tourne toujours bien aujourd'hui
Je n'ai jamais compris pourquoi ces protocoles suscitaient autant de confusion, et presque tous les ingénieurs juniors avec qui j'ai travaillé avaient du mal à les comprendre. Le blog de Scott Brady https://www.scottbrady.io/ aide énormément sur ce sujet
Dès qu'il est question d'authentification et d'autorisation, les ingénieurs semblent ressentir une forme de « peur » primitive. Ils ont l'habitude de résoudre des problèmes, mais ici l'authentification et l'autorisation s'imposent comme des prérequis à cette résolution, ce qui crée un coût cognitif
Du Cloudflare typique. Ça fonctionne bien pour tout le monde et ce n'est pas très cher, mais le résultat de tous ces avantages, c'est que l'entreprise se retrouve au centre de tout
Ici Grant. Avec Aeneas, j'ai écrit l'essentiel du code de migration 2.0. Merci à l'équipe Cloudflare pour cet article
Je me demande si le passage « Notre enquête a montré qu'un problème dans l'une des migrations Hydra avait corrompu l'état de certaines sessions OAuth valides, ce qui a conduit la migration à marquer ces sessions comme invalides » faisait référence à l'un des fichiers de migration open source
Je ne suis plus impliqué dans le projet, mais j'aimerais savoir si cela a été corrigé en amont
Au minimum, le contexte global devrait inclure un plan pour les flux d'autorisation et d'authentification dans l'écosystème Cloudflare, donc j'ai des sentiments partagés. Il n'y a même pas d'exemple sur GitHub
Cela dit, Cloudflare est bien parti dans la bonne direction, mais il reste encore beaucoup de chemin à parcourir face à l'ensemble de la suite Ory sous-jacente. Ory Kratos gère l'identité, la connexion, l'inscription, la récupération, l'authentification multifacteur, etc. : https://github.com/ory
À mon avis, le périmètre complet devrait aussi inclure un annuaire d'utilisateurs, SAML et un plan pour un modèle d'organisation multi-tenant. Un bon exemple est Zitadel https://github.com/zitadel qui fournit une interface d'administration pour le multi-tenant organisationnel, la prise en charge d'OIDC/PKCE, et permet aussi d'ajouter une certaine forme de RBAC
Supabase propose également une authentification managée et open source : https://github.com/supabase/auth
Indépendamment du débat « MCP est mort, vive Skills », ce qui m'inquiète, c'est qu'un projet massif autour de l'intégration de MCP partout et de la rotation des clés semble prêt à exploser très bientôt
Enregistrement dynamique de clients OAuth 2.0 (RFC 7591) : https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
J'aimerais particulièrement entendre des avis dans le contexte des SaaS multi-tenant et des assistants IA intégrés
Dans le flux de redirection généralement utilisé pour connecter MCP à un agent, la spécification ne dit presque rien sur la manière de rendre cela sûr
On n'a pas envie de laisser n'importe qui enregistrer un client avec un callback arbitraire. C'est ouvrir la porte au phishing
Si quelqu'un enregistre un client avec une URL de callback malveillante puis trompe un utilisateur pour qu'il clique sur un lien lançant ce flux, un fournisseur d'identité légitime authentifiera l'utilisateur puis transmettra le jeton d'accès à l'attaquant
La spécification balaie cela un peu vite en évoquant un jeton d'accès initial que le client doit obtenir avant l'enregistrement, mais les détails manquent, et dans un scénario où tous les utilisateurs finaux deviennent des clients, cela fonctionnera probablement mal
Idéalement, j'aimerais pouvoir définir une liste d'autorisation de motifs de redirection pour limiter cela à des cibles comme ChatGPT. Mais c'est un comportement non standard, donc les fournisseurs IAM ne se précipitent pas
Je ne comprends pas l'intention ici. Je ne vois aucun monde où cela se termine bien. Cloudflare est pratiquement un fournisseur d'infrastructure, et un modèle d'infrastructure où un utilisateur peut déléguer les permissions de son compte à un client tiers présente un fort potentiel d'abus
Si une entreprise comme AWS ne le fait pas, il doit bien y avoir une raison
Par exemple, IAM peut donner à des GitHub Actions exécutées depuis un dépôt précis la permission de mettre à jour Lambda
OAuth et l’authentification d’entreprise sont peut-être ce qu’on a fait de pire. C’est sans doute l’un des aspects les plus confus et frustrants du cloud
Même les outils d’IA ont mis un an rien que pour gérer l’OAuth de base dans des systèmes headless, sans partir du principe qu’ils peuvent ouvrir un navigateur
Si on doit descendre dans tous les terriers de lapin de l’authentification des grands fournisseurs cloud — RBAC/IAM/identité de workload/comptes de service et compagnie — j’aimerais vraiment qu’on laisse au moins une méthode simple pour un usage individuel
Une simple clé API suffit. Il suffit de la garder secrète et de la révoquer si besoin, pas d’empiler 10 000 couches de bric-à-brac d’authentification à tous les niveaux de toutes les plateformes
C’est un cauchemar pour la vie privée
On vient aussi de lancer Ory Talos(https://github.com/ory/talos) pour les clés API. C’est une bonne alternative quand OAuth2 est disproportionné par rapport au cas d’usage
Il existe aussi des cas d’usage et des préoccupations de sécurité qui justifient l’emploi d’OAuth2. Des spécifications comme DPoP peuvent rendre ces flux plus sûrs
Le cas d’usage présenté ici semble bien convenir à OAuth2, mais ce n’est pas adapté partout. La complexité rend aussi la sécurisation des systèmes plus difficile
L’avantage d’OAuth2/OIDC, c’est que la confiance n’est pas placée dans le détenteur de la clé API, mais dans l’identité réelle qui a besoin d’accéder
Le fait que l’authentification soit difficile concerne surtout l’authentification pour beaucoup d’utilisateurs. L’authentification pour soi-même est très simple, et c’est encore plus facile avec un framework correct
Si vous doutez de votre implémentation, vous pouvez la soumettre à l’un des modèles récents. Ils sont assez bons pour repérer les problèmes dans un système d’authentification aussi simple
« Ory Enterprise License : débloque des fonctionnalités de niveau entreprise comme SLA de sécurité CVE, SAML, organisations B2B, multi-tenant et meilleure scalabilité » [0]
Ou alors on peut simplement continuer à utiliser Keycloak, qui propose un produit entièrement auto-hébergé [1]
[0]https://github.com/ory
[1]https://www.keycloak.org/
S’il existe une version commerciale, c’est parce qu’il faut bien résoudre la question de la viabilité financière d’un open source de classe mondiale. Le fait qu’il existe un modèle économique viable pour un projet open source qui soutient les plus grandes entreprises logicielles du monde n’est pas une mauvaise chose, c’est une bonne chose
D’ailleurs, IBM aussi a trouvé un moyen de gagner de l’argent avec Keycloak
Ici, on parle essentiellement d’OAuth pour l’accès au compte Cloudflare, pas d’une fonctionnalité générique de type « connexion » hébergée par Cloudflare pour des applications personnalisées
Je pensais avoir compris ce qu’est OAuth, mais cet article m’embrouille. Je voyais ça comme un protocole standardisé fournissant des clés d’accès par client
Que signifie OAuth autogéré ici ? Il faut expliquer à quoi l’accès est accordé, qui est le client et qui est le partenaire
Cela permet d’héberger soi-même un système OAuth chargé d’autoriser ou de refuser l’accès à ses propres ressources. Au lieu d’attendre que Cloudflare autorise Y sous la condition X, on peut créer la logique souhaitée
En substance, le flux est : « se connecter à Cloudflare » → Cloudflare vérifie l’usage d’un OAuth autogéré → redirection vers votre OAuth → Cloudflare fait confiance à la réponse → si l’utilisateur autorise, l’accès au compte est accordé