Cloudflare construit OAuth avec Claude et rend publics tous les prompts

• Cloudflare a présenté un framework provider OAuth 2.1 sous forme de bibliothèque TypeScript pour Cloudflare Workers
• L’essentiel de l’implémentation a été écrit à l’aide du LLM Claude d’Anthropic, puis minutieusement relu par des ingénieurs sécurité de Cloudflare
• Cette bibliothèque fournit l’automatisation de l’authentification pour les endpoints d’API et la gestion automatique des tokens
• Elle prend en charge les fonctions clés comme les standards OAuth les plus récents et PKCE, l’enregistrement dynamique des clients et la définition des scopes d’accès
• Elle met l’accent sur une conception orientée sécurité, avec notamment le chiffrement de bout en bout aux étapes critiques et des refresh tokens à usage unique

---

Présentation et importance du framework provider OAuth 2.1 pour Cloudflare Workers

Ce projet open source est une bibliothèque TypeScript conçue pour implémenter facilement un serveur d’authentification OAuth 2.1 dans l’environnement Cloudflare Workers.
Par rapport à d’autres projets comparables, ses points forts sont une grande extensibilité et une intégration fluide spécifiquement pensées pour la plateforme Cloudflare, ainsi qu’une conception centrée sur la sécurité
L’accent est mis sur les algorithmes, le respect des standards de protocole (RFC-8414, RFC-7591, etc.) et la clarté de la structure de la bibliothèque
En particulier, la sécurité fait l’objet d’une conception détaillée, avec par exemple le stockage haché des tokens et des principales valeurs secrètes, ainsi que le chiffrement de bout en bout des props
À noter que la majeure partie du code cœur de la bibliothèque et de sa documentation a été rédigée avec l’aide du LLM Claude, ce qui en fait un exemple de développement particulièrement intéressant

Principales fonctionnalités et avantages

• En enveloppant le code Worker avec OAuthProvider, il est possible d’ajouter automatiquement des fonctions d’authentification aux endpoints d’API
• La gestion des tokens (création, stockage, validation, révocation, etc.) est automatisée, sans nécessité de l’implémenter soi-même
• Dans le gestionnaire fetch, l’utilisateur peut exploiter directement les informations d’un utilisateur déjà authentifié, reçues en paramètre
• Aucune contrainte sur la gestion des utilisateurs, l’authentification ou l’implémentation de l’UI (le développeur peut librement choisir l’architecture et le framework souhaités)
• Le stockage de la bibliothèque ne conserve que des informations hachées ; les secrets eux-mêmes, comme les clés secrètes, ne sont pas stockés

Points clés d’utilisation

• Une instance OAuthProvider peut être exportée comme point d’entrée du Worker pour jouer le rôle de gestionnaire fetch
• Les options apiRoute et apiHandler permettent de définir respectivement la zone des endpoints d’API qui requiert une authentification et le gestionnaire réel
• Il est possible de définir les chemins des endpoints OAuth standard comme authorizeEndpoint, tokenEndpoint et clientRegistrationEndpoint
• Si nécessaire, il est possible d’affiner les politiques, comme les scopes ou l’enregistrement des clients publics
• Via defaultHandler, les requêtes hors API ainsi que les requêtes en échec d’authentification peuvent aussi être traitées avec souplesse

Objets helpers et API

• env.OAUTH_PROVIDER peut être utilisé dans le gestionnaire fetch pour traiter l’analyse des requêtes liées à OAuth, la consultation des informations client ou la finalisation d’une autorisation
• Lors du traitement d’une requête API, si l’access token est valide, les props propres à l’utilisateur autorisé sont directement accessibles via ctx.props
• L’API officielle permet aussi l’enregistrement des clients, la consultation de la liste des grants, ainsi que l’affichage et la révocation des grants pour un utilisateur donné

Token Exchange Callback

• Prise en charge d’un callback (tokenExchangeCallback) permettant de mettre à jour dynamiquement les valeurs de props lors de l’émission ou du renouvellement d’un token
• Il devient ainsi possible de gérer des scénarios complexes, comme un échange de tokens additionnel lié au client OAuth (upstream token exchange)
• Le callback peut renvoyer accessTokenProps, newProps et accessTokenTTL afin d’implémenter un comportement personnalisé
• En personnalisant accessTokenTTL, il est possible d’aligner le moment d’expiration du token sur celui d’un système OAuth amont
• Comme les props peuvent contenir des informations sensibles, l’ensemble de ces valeurs est stocké avec un chiffrement de bout en bout

Réponses d’erreur personnalisées

• L’option onError permet de déclencher des actions externes en cas d’erreur, comme l’envoi de notifications ou un logging personnalisé
• Si une Response est renvoyée explicitement, il est possible de surcharger le format de la réponse d’erreur fournie à l’utilisateur par OAuthProvider

Détails de conception liés à la sécurité

Chiffrement de bout en bout

• Les données liées aux tokens et les secrets ne sont stockés que sous forme de hachages, et les informations de props des grants sont stockées chiffrées à l’aide du token lui-même, ce qui améliore la résilience en cas de fuite
• userId, metadata, etc. ne sont pas chiffrés afin de conserver des traces pour l’audit et la révocation ; le développeur peut toutefois ajouter un chiffrement supplémentaire si nécessaire

Conception des refresh tokens à usage unique

• Conformément aux exigences d’OAuth 2.1 sur la condition de « liaison au client ou usage unique », cette bibliothèque adopte un compromis en autorisant au maximum deux refresh tokens en parallèle
• Cela fournit un garde-fou permettant de réutiliser une fois l’ancien token si l’enregistrement du nouveau token échoue, par exemple à cause d’un incident réseau

Processus de développement avec Claude

• Une grande partie des premières versions de cette bibliothèque et de sa documentation a été produite avec le LLM Claude d’Anthropic, puis relue avec soin par des ingénieurs Cloudflare au regard des RFC et des exigences de sécurité
• Au départ, l’équipe était sceptique vis-à-vis de la génération de code par l’IA, mais l’expérience concrète en matière de qualité et de gains de productivité a fait évoluer cette perception
• Le flux de développement, les prompts adressés à Claude et le processus d’amélioration du code sont tous rendus publics de manière transparente dans l’historique des commits Git

Autres éléments

• La liaison au namespace Workers KV (OAUTH_KV) est obligatoire ; voir storage-schema.md
• Pour l’ensemble de l’API et des helpers, se référer à la définition de l’interface OAuthHelpers
• La bibliothèque est actuellement en phase bêta / prérelease et son API peut encore évoluer

---

[GN⁺]

Commentaires sur Hacker News

• Présentation d’un extrait du README. Cette bibliothèque (et la documentation du schéma) a été écrite en grande partie avec l’aide de Claude, le modèle d’IA d’Anthropic. Les ingénieurs de Cloudflare l’ont examinée de manière approfondie, en veillant à la sécurité et à la conformité aux standards. De nombreuses améliorations ont été apportées dès les premiers résultats, principalement en donnant à Claude des prompts supplémentaires puis en réexaminant itérativement les résultats. On peut vérifier directement dans l’historique des commits comment Claude a été sollicité et quel code en est sorti. Au départ, la position sceptique traditionnelle était : « il ne faut pas laisser un LLM écrire une bibliothèque d’authentification ». Même en janvier 2025, j’étais moi-même très sceptique vis-à-vis de l’IA, pensant que les LLM n’étaient guère plus que de « luxueux générateurs de chaînes de Markov » incapables d’apporter de la nouveauté ou de produire du vrai code. J’ai commencé ce projet pour m’amuser, mais j’ai été choqué de voir qu’il produisait du code meilleur que prévu. Ce n’était pas parfait, mais quand on demandait à l’IA de corriger, elle corrigeait correctement. Chaque ligne a été comparée à divers RFC et relue avec des experts en sécurité. J’essayais de valider mon scepticisme, et le résultat a au contraire prouvé que j’avais tort. Il faut vraiment consulter l’historique des commits, surtout les premiers, pour voir ce processus

  • Je m’attends à ce qu’un LLM soit tout à fait capable de produire ce genre de code lorsqu’un ingénieur expérimenté le prompt correctement. OAuth n’est pas une technologie nouvelle, et il existe déjà d’innombrables exemples open source ainsi que des implémentations dans différentes langues qui ont probablement servi de données. En revanche, je reste sceptique face à l’idée que les LLM puissent contribuer de façon révolutionnaire à des recherches entièrement nouvelles, à la science des matériaux, à l’économie, à l’invention, etc. Ce sont des domaines où la « capacité à apprendre en temps réel » est vraiment nécessaire, alors que les LLM actuels n’ont montré leurs capacités qu’à partir d’informations anciennes qu’ils connaissaient déjà. Les résultats significatifs semblent le plus souvent n’être que des cas cherry-pick dans des environnements très limités. S’il y a un ingénieur expérimenté, il me paraît naturel qu’on puisse générer du nouveau code à partir de données passées, mais je continue à me demander si le coût environnemental et social de l’adoption des LLM n’est pas excessif par rapport au gain réel d’efficacité

  • La formulation « jusqu’en janvier 2025, j’avais la même opinion que (@kentonv) » me semble confuse, car kentonv est un autre utilisateur. Je me demande s’il s’agit d’un compte secondaire de l’auteur, ou d’une faute, ou d’un malentendu. Édition : j’ai constaté que la majeure partie du texte cite le README. Je pense qu’il y aurait eu moins de confusion si les citations avaient été clairement marquées avec les symboles > et *. J’ajoute le lien vers le profil de kentonv

  • « Je pensais que les LLM étaient de luxueux générateurs de chaînes de Markov » et « j’ai été surpris que l’IA produise du code plutôt correct » ne sont pas deux opinions contradictoires. Je trouve les LLM extrêmement utiles, mais leur nature reste proche de celle d’un générateur de motifs. Le point important, c’est que cela est déjà suffisant, et que les humains eux-mêmes ne sont peut-être pas structurés de manière si différente

  • En ce moment, je suis plus sceptique que pro-IA, mais je continue malgré tout à essayer d’intégrer l’IA dans mon workflow. En pratique, l’expliquer est plus difficile, donc j’ai souvent l’impression qu’il est plus simple de le faire moi-même. Ce n’est pas très amusant non plus, mais je pense qu’il est judicieux d’apprendre cet outil, puisque c’est l’outil du « futur ». J’estime que le vrai tooling IA en est encore à ses tout débuts. Je continue à m’intéresser aux futurs cas d’usage UX qui seront étonnants

  • Indication de consulter directement l’historique des commits pour voir comment Claude a été prompté au départ et comment il a réellement généré le code. Lien direct vers la page du premier commit. Il y avait beaucoup d’instructions claires et précises, et des exemples de commit 1 et 2 valent aussi le détour

• Extrait d’un commit problématique de Cloudflare workers-oauth-provider. Claude avait introduit un bug dans un commit précédent, et on a essayé plusieurs fois de le corriger via des prompts, sans succès. Finalement, un humain l’a corrigé directement et a même documenté dans le README un problème de spécification OAuth 2.1. Cette expérience me parle beaucoup dans mon propre usage de l’IA : je la vois souvent bien avancer jusqu’à un certain point, puis peiner pour le reste

  • Je relève que l’IA s’en sort bien jusqu’à mi-parcours, mais qu’une fois qu’elle se trompe, tout ce qui suit part en vrille. Lorsqu’on détecte l’erreur, il faut immédiatement réécrire le prompt depuis le début de la conversation et repartir de zéro. Après une première erreur, même si l’on essaie de corriger, les résultats continuent souvent à être faux. Il faut donc tout reformuler clairement dans un bon message initial et reconstruire depuis le début pour éviter que l’erreur ne se répète

  • Pour atténuer ce problème, il est utile de préparer des tests ou une spécification claire, puis de demander à l’IA de résoudre cela. Il y a encore quelques mois, les IA mettaient beaucoup de temps à résoudre ce type de puzzle basé sur une spec, et les résultats étaient de moins bonne qualité que des réponses rapides. Mais récemment, les modèles se sont beaucoup améliorés, au point que ce genre de travail devient assez intéressant, et leur utilité augmente quand le problème peut être spécifié formellement. Personnellement, j’ai trouvé que sonnet 3.7 représentait un grand progrès par rapport à 3.5, et Gemini 2.5 Pro m’a encore plus impressionné. sonnet 4 fait moins d’erreurs, mais il faut toujours bien guider l’IA d’un point de vue ingénierie logicielle — clarification des besoins, exploration des solutions techniques, conception de l’architecture, rédaction des user stories et des specs, écriture du code — pour obtenir des résultats de qualité. En plus, l’ajout de bons exemples dans le contexte de l’IA maximise l’efficacité. Récemment, quand j’ai développé une app avec l’OpenAI Realtime API, ce fut un échec total au début, puis dès que j’ai ajouté deux pages de documentation et un projet démo au workspace, j’ai obtenu immédiatement le résultat souhaité (dans mon cas, même en devant utiliser l’API différemment, cela collait très bien)

  • Dans les lignes 163 à 172 du commit, j’ai repéré des affirmations manifestement inexactes ou dont l’interprétation varie selon les implémentations d’A/S (serveur d’autorisation). Le serveur d’autorisation d’Auth0 prévoit un réglage de « leeway » tenant compte des conditions réseau, mais certains autres serveurs sont bien plus stricts. Chaque implémentation ayant ses propres choix de conception, je pense que la probabilité qu’un LLM implémente cela en toute sécurité à partir des seuls standards (RFC) et de l’open source public reste conditionnée à un niveau de supervision humaine finalement comparable à celui d’une implémentation faite directement à la main

  • Je serais curieux de voir des résultats de recherche à long terme sur la question de savoir si les outils à base de LLM économisent réellement du travail humain, ou s’ils ne produisent qu’une illusion de productivité

  • À travers ce type d’expérience, je considère que ces outils d’IA ne « comprennent » pas réellement ; ils produisent plutôt des sorties émergentes et contingentes à partir d’un énorme ensemble de motifs appris

• L’avenir du code assisté par IA ne ressemble sans doute pas au fantasme LinkedIn/X où les ingénieurs logiciel disparaissent et où un business man appuie sur un bouton pour tout terminer. Il ressemblera plutôt à des ingénieurs expérimentés qui utilisent l’IA pour produire une partie du code, puis l’examinent, le testent et le valident soigneusement. La vraie question est donc : « kentonv aurait-il pu créer cette bibliothèque plus vite, seul et sans IA ? »

  • Construire la bibliothèque avec l’IA a pris quelques jours. La faire à la main aurait probablement pris plusieurs semaines, peut-être même plusieurs mois. Cela dit, c’est ici un cas très idéal. Cela n’a été possible que parce qu’il y avait des standards clairs, une spec d’API claire, et une plateforme déjà bien connue. Quand j’ai essayé d’utiliser l’IA pour modifier le Workers Runtime lui-même, le gain de temps a été bien moindre. En revanche, pour explorer la codebase d’autres personnes que je connais mal, l’IA est une aide énorme. Il est désormais beaucoup plus facile d’entrer dans des environnements complexes et inconnus ; autrefois j’évitais ce genre de choses, alors qu’aujourd’hui je peux effectuer moi-même les changements nécessaires plus facilement

  • À la question de savoir si cela aurait été plus rapide sans IA, je pense clairement que non. Avec les outils dont nous disposons aujourd’hui et le savoir-faire d’usage qui continue à progresser, il est probable que d’ici 3 à 6 mois, coder directement de nouvelles solutions avec l’IA sera encore plus rapide. Mais je pense qu’il est important d’avoir des codebases bien documentées, bien structurées, avec une boucle de feedback rapide (bons linters/tests unitaires). C’est vers cela que nous allons

  • D’après mon expérience, quand l’IA écrit une partie du code, il faut ensuite le relire et le tester minutieusement, et ce processus est au contraire plus <i>lent</i> que de coder moi-même. Donc, à ce stade, l’IA ne m’aide pas beaucoup. Comme le dit le proverbe sur le mauvais assistant, il vaut parfois mieux ne pas en avoir du tout : pour l’instant, l’IA est encore un « mauvais assistant »

  • Si le modèle est « des ingénieurs expérimentés font générer une partie du code par l’IA puis le relisent et le testent avec soin », cela ne signifie-t-il pas qu’au lieu de 20 kentonv, 2 suffiraient ? Continuera-t-on à créer du travail pour les 18 autres ? Le cas de l’auteur concerne un projet techniquement difficile, mais je me demande quels changements cela apportera au développement d’applications LoB plus banales

  • Si seuls des ingénieurs expérimentés relisent et testent minutieusement, et que tous les postes de développeurs juniors sont remplacés par l’IA, d’où viendront les futurs développeurs expérimentés ? Je continue à voir une réelle valeur même dans les tâches simples et répétitives

• Le fait même de voir tous ces points de vue et opinions différents est fascinant. J’apprécie que Cloudflare, en tant que leader de la sécurité sur Internet, montre une tentative de nouvelle forme de « vibe coding » pour connecter le monde. J’ai le sentiment que le fait de rendre publics ces prompts IA, ce code, etc., encourage aussi d’autres développeurs à explorer davantage la programmation. Le vibe programming a été pour moi un moyen très significatif de sortir d’un état dépressif et de recommencer à coder d’une manière qui me convient. J’espère que ce type d’expérience pourra aider d’autres personnes. Je pense que les générations actuelles et futures utiliseront toutes cette approche. Mais il faut aussi discuter du fait que cette manière de faire peut être liée à la santé mentale et aux problèmes psychologiques. En fin de compte, il faut garder à l’esprit que ces outils sont des auxiliaires pour l’humain, et réfléchir à la manière de les utiliser pour continuer à grandir avec passion. J’espère voir émerger davantage d’exemples, dans l’open source, qui montrent non seulement des compétences techniques, mais aussi une approche des projets fondée sur la logique et la réflexion. Encore une fois, bravo à Cloudflare

• Une compilation d’exemples représentatifs d’échanges de prompts a été rassemblée. Dans cet exemple de transcription de prompts, le coût réel total ($6.45) est même rendu public. Des ressources comme ce commit lié 1 et ce commit 2 sont aussi indiquées. Il est surprenant qu’il y ait si peu de vrais retours d’expérience sérieux sur les workflows IA (en particulier de la part de personnes expérimentées), tant ils sont noyés dans le hype. Au-delà des todo lists, je voudrais voir davantage d’exemples de vrai live coding. Les textes d’antirez et de tptacek (cas d’antirez, texte de tptacek) peuvent aussi être utiles

  • Je n’ai pas fait un suivi exact, mais j’estime le coût d’utilisation de Claude à environ $50. Par rapport au temps économisé, c’est négligeable

• Je pense que le « vibecoding » ne survivra pas au final. Il faut toujours la validation et le débogage d’excellents programmeurs, et il y a même eu des bugs que l’IA n’a pas réussi à corriger. Au fond, ce type d’outil reste un outil d’assistance permettant à quelqu’un qui maîtrise déjà bien la tâche d’aller plus vite. Pour une homepage vraiment basique à la rigueur, mais des outils capables de générer cela existent déjà depuis des années

  • Le vibecoding est aujourd’hui surtout adapté aux travaux à faible enjeu. GUI, applis CRUD, expérimentations ponctuelles, etc. : il est particulièrement utile là où il donne du pouvoir à des personnes qui en avaient peu. Dans ce cas précis, je ne pense pas qu’il s’agisse de vibecoding, mais plutôt de LLM-assisted coding

  • En pratique, j’ai l’impression que le terme vibecoding est souvent utilisé comme un homme de paille polémique. Après tout, si l’on prend du code produit par un LLM et qu’on ne le modifie qu’un peu avant de l’utiliser, n’est-ce pas aussi une forme de vibe coding ?

• Je remercie énormément l’OP d’avoir publié non seulement le code généré par l’IA, mais aussi les prompts. Personnellement, j’essaie avec des LLM de développer du code non web (ces temps-ci, notamment une implémentation .NET pour rétroconcevoir du SAP ABAP et adapter les données à Snowflake), et je souffre constamment d’hallucinations. Comme j’entendais beaucoup de gens parler de leurs réussites, je pensais que le problème venait uniquement de mes prompts, mais ce cas publié me montre que je ne suis pas si loin. Si les LLM fonctionnent mal pour moi, c’est probablement parce que le problème que je traite est un peu rare et nouveau. Si le sujet n’est pas massivement appris comme le cas OAuth publié sur GitHub, les LLM suivent beaucoup moins bien

• Ce type de code répétitif, déjà implémenté des centaines de fois, convient parfaitement à l’IA. Le tout fait environ 1 200 lignes, donc cela reste petit. Je suis même surpris que cela ait pris plus de deux jours malgré l’usage de l’IA

• Ces derniers mois, j’ai mené mon propre projet greenfield avec Claude via Cursor, et j’en retiens trois choses : premièrement, ma productivité a énormément augmenté. Deuxièmement, je suis mentalement bien plus fatigué qu’avant. Troisièmement, même à court terme, les outils commencent à progresser très vite, ce qui amplifie encore les deux effets précédents

  • C’est exactement aussi mon expérience, ainsi que celle d’autres développeurs autour de moi. Le LLM-assisted coding améliore réellement la productivité, mais il consomme d’autant plus d’énergie. C’en est presque étrange

  • Je m’interroge sur ce point du « c’est plus fatigant ». Moi, je l’utilise plutôt comme du « pair programming » avec mon agent (Devstral), et je trouve qu’il est bien plus facile de relire le code que de tout taper soi-même. En termes de temps, c’est un gros avantage. Avec le vibe coding, on perd le contexte de la codebase, ce qui rend la relecture ultérieure et l’entrée dans le projet beaucoup plus difficiles. En pair programming, au contraire, le contexte s’accumule au fil du travail, donc la revue me semble bien plus rapide

  • Moi, c’est exactement l’inverse. Comme l’IA gère automatiquement tous les petits détails, j’éprouve au contraire un grand soulagement. Cela me libère pour me concentrer sur les objectifs de plus haut niveau, comme l’architecture

• Je trouve assez amusant qu’une entreprise comme Cloudflare déclenche une erreur « Too Many Requests »

  • Moi aussi