Cloudflare baut OAuth mit Claude und legt alle Prompts offen

• Cloudflare hat ein OAuth-2.1-Provider-Framework als TypeScript-Bibliothek für Cloudflare Workers angekündigt
• Der Großteil der Implementierung wurde mit Anthropics Claude LLM geschrieben und anschließend von Cloudflare-Sicherheitsingenieuren sorgfältig überprüft
• Die Bibliothek bietet automatisierte Authentifizierung für API-Endpunkte und automatische Token-Verwaltung
• Sie unterstützt aktuelle OAuth-Standards und PKCE, dynamische Client-Registrierung, Scope-Konfiguration und weitere Kernfunktionen
• Cloudflare betont ein Sicherheitsdesign mit Ende-zu-Ende-Verschlüsselung an kritischen Stellen und Single-Use-Refresh-Tokens

---

Einführung und Bedeutung des OAuth-2.1-Provider-Frameworks für Cloudflare Workers

Dieses Open-Source-Projekt ist eine TypeScript-Bibliothek, die dafür entwickelt wurde, einen OAuth-2.1-Authentifizierungsserver in der Cloudflare-Workers-Umgebung einfach zu implementieren.
Im Vergleich zu ähnlichen Projekten liegen die Stärken in der auf die Cloudflare-Plattform zugeschnittenen Skalierbarkeit und nahtlosen Integration sowie im sicherheitsorientierten Design
Der Schwerpunkt liegt auf Algorithmen, der Einhaltung von Protokollstandards (RFC-8414, RFC-7591 usw.) und einer klaren Bibliotheksstruktur
Insbesondere wurden Details wie die gehashte Speicherung von Tokens und wichtigen Secret-Werten sowie die Ende-zu-Ende-Verschlüsselung von Props gezielt für hohe Sicherheit entworfen
Bemerkenswert ist außerdem, dass der Großteil des Core-Codes und der Dokumentation der Bibliothek in Zusammenarbeit mit Claude LLM erstellt wurde und damit ein interessantes Entwicklungsbeispiel zeigt

Wichtige Funktionen und Vorteile

• Durch das Wrapping von Worker-Code mit OAuthProvider wird Authentifizierung für API-Endpunkte automatisch hinzugefügt
• Token-Verwaltung (Erstellung, Speicherung, Validierung, Widerruf usw.) wird automatisch verarbeitet, sodass keine eigene Implementierung nötig ist
• Nutzer können innerhalb des Fetch-Handlers bereits authentifizierte Benutzerinformationen direkt als Parameter erhalten und verwenden
• Es gibt keine Einschränkungen bei Benutzerverwaltung, Authentifizierung oder UI-Implementierung (Entwickler können Struktur und Framework frei wählen)
• Im Speicher der Bibliothek werden nur Hash-Informationen gespeichert; Secrets wie geheime Schlüssel selbst werden nicht abgelegt

Kernelemente der Nutzung

• Eine OAuthProvider-Instanz kann als Worker-Entrypoint exportiert werden und die Rolle des Fetch-Handlers übernehmen
• Mit den Optionen apiRoute und apiHandler werden jeweils der Bereich der API-Endpunkte, die Authentifizierung benötigen, und der eigentliche Handler festgelegt
• Standardisierte OAuth-Endpunktpfade wie authorizeEndpoint, tokenEndpoint und clientRegistrationEndpoint lassen sich definieren
• Bei Bedarf lassen sich Richtlinien wie Scope oder Public-Client-Registrierung feiner abstufen
• Über defaultHandler können auch Nicht-API-Anfragen und fehlgeschlagene Authentifizierungsanfragen flexibel behandelt werden

Helper-Objekte und API

• env.OAUTH_PROVIDER kann im Fetch-Handler verwendet werden, um OAuth-bezogene Requests zu parsen, Client-Informationen abzurufen oder Autorisierungen abzuschließen
• Bei der Verarbeitung von API-Requests ist bei gültigem Access Token ein direkter Zugriff auf benutzerspezifische Props-Informationen im autorisierten Zustand über ctx.props möglich
• Auch Client-Registrierung, Listen von Berechtigungen (authorization grants) sowie das Einsehen und Widerrufen von Grants für bestimmte Benutzer werden über die offizielle API bereitgestellt

Token Exchange Callback

• Beim Ausstellen oder Erneuern von Tokens wird ein Callback (tokenExchangeCallback) unterstützt, mit dem Props-Werte dynamisch aktualisiert werden können
• Dadurch sind auch komplexere Szenarien wie zusätzlicher Token-Austausch mit einem OAuth-Client (upstream token exchange) möglich
• Im Callback können accessTokenProps, newProps und accessTokenTTL zurückgegeben werden, um benutzerdefiniertes Verhalten zu implementieren
• Durch die Anpassung von accessTokenTTL lässt sich der Zeitpunkt des Token-Ablaufs mit einem übergeordneten OAuth-System abstimmen
• Da Props sensible Informationen enthalten können, wird dieser gesamte Wert Ende zu Ende verschlüsselt gespeichert

Benutzerdefinierte Fehlerantworten

• Mit der Option onError lassen sich bei Fehlern externe Maßnahmen wie das Senden von Benachrichtigungen oder Custom Logging auslösen
• Wird eine Response direkt zurückgegeben, kann die von OAuthProvider an Benutzer gelieferte Fehlerantwort in der gewünschten Form überschrieben werden

Detailliertes Sicherheitsdesign

Ende-zu-Ende-Verschlüsselung

• Token-bezogene Daten und Secrets werden nur als Hash gespeichert; Grant-Props-Informationen werden mit dem Token selbst verschlüsselt gespeichert, um die Widerstandsfähigkeit bei Sicherheitsvorfällen zu erhöhen
• userId, metadata usw. werden für Audit- und Widerrufszwecke nicht verschlüsselt gespeichert; bei Bedarf können Entwickler zusätzliche Verschlüsselung anwenden

Single-Use-Refresh-Token-Design

• Entsprechend der OAuth-2.1-Anforderung „Client-Binding oder Single-Use“ verwendet diese Bibliothek als Kompromiss ein Design, das maximal zwei parallele Refresh Tokens erlaubt
• Dadurch gibt es einen Sicherheitsmechanismus, mit dem ein vorheriges Token noch einmal verwendet werden kann, selbst wenn das Speichern des neuen Tokens wegen Netzwerkproblemen fehlschlägt

Entwicklungsprozess auf Basis von Claude

• Ein großer Teil dieser Bibliothek und der Dokumentation wurde mit Anthropic Claude LLM entworfen; Cloudflare-Ingenieure haben das Ergebnis sorgfältig anhand von RFCs und Sicherheitsstandards geprüft
• Anfangs stand man AI-gestützter Codegenerierung skeptisch gegenüber, doch durch die tatsächlich erlebten Verbesserungen bei Qualität und Produktivität änderte sich diese Sichtweise
• Entwicklungsablauf, Claude-Prompts und der Prozess der Codeverbesserung werden über die Git-Commit-Historie vollständig und transparent offengelegt

Sonstiges

• Die Bindung eines Workers-KV-Namespace (OAUTH_KV) ist zwingend erforderlich; siehe storage-schema.md
• Für die vollständige API und alle Helper siehe die Definition des Interfaces OAuthHelpers
• Die Bibliothek befindet sich derzeit in der Beta-/Pre-Release-Phase; künftige API-Änderungen sind möglich

---

[GN⁺]

Hacker-News-Kommentare

• Auszug aus dem Readme. Diese Bibliothek (und die Schema-Dokumentation) wurde größtenteils mit Hilfe von Anthropics KI-Modell Claude geschrieben. Cloudflare-Ingenieure haben alles gründlich geprüft und auf Sicherheit sowie Standardkonformität geachtet. Schon an den ersten Ergebnissen wurde viel verbessert, vor allem indem man Claude zusätzliche Prompts gab und die Resultate wiederholt überprüfte. Im Commit-Verlauf kann man direkt nachvollziehen, wie Claude gepromptet wurde und welcher Code dabei entstand. Anfangs war die klassische skeptische Haltung: „Man sollte ein LLM keine Authentifizierungsbibliothek schreiben lassen.“ Noch im Januar 2025 war auch ich sehr skeptisch gegenüber KI und dachte, LLMs seien nur „verzierte Markov-Ketten-Generatoren“, die weder etwas wirklich Neues noch brauchbaren Code hervorbringen könnten. Das Projekt begann aus Spaß, aber ich war schockiert, dass überraschend guter Code herauskam. Perfekt war er nicht, aber wenn man die KI um Korrekturen bat, hat sie ihn ordentlich verbessert. Zeile für Zeile wurde alles mit verschiedenen RFCs verglichen und gemeinsam mit Sicherheitsexperten geprüft. Ich wollte meinen Skeptizismus überprüfen, und am Ende habe ich eher bewiesen, dass ich selbst falschlag. Im Commit-Verlauf, besonders in den frühen Commits, kann man diesen Prozess gut nachvollziehen

  • Ich würde erwarten, dass ein LLM solchen Code durchaus erzeugen kann, wenn ein erfahrener Ingenieur es richtig promptet. OAuth ist keine neue Technologie, und es dürfte bereits unzählige Open-Source-Beispiele sowie Implementierungen in verschiedenen Sprachen als Trainingsdaten gegeben haben. Ich bin aber weiterhin skeptisch gegenüber Behauptungen, LLMs würden völlig neue Forschung, Materialwissenschaft, Wirtschaft oder Erfindungen revolutionär voranbringen. Gerade dort ist die Fähigkeit, „in Echtzeit zu lernen“, wirklich nötig, und heutige LLMs haben ihre Stärke bisher nur auf Basis bereits bekannter älterer Informationen gezeigt. Bedeutende Resultate sind meist nur sorgfältig herausgepickte Beispiele aus sehr eingeschränkten Umgebungen. Mit einem erfahrenen Ingenieur erscheint es mir selbstverständlich, dass auf Basis historischer Daten neuer Code erzeugt werden kann, aber ich frage mich weiterhin, ob die ökologischen und gesellschaftlichen Kosten des LLM-Einsatzes nicht in keinem guten Verhältnis zur tatsächlichen Effizienz stehen

  • Ich war verwirrt von der Formulierung „Bis Januar 2025 dachte ich genauso wie (@kentonv)“, weil kentonv ein anderer Nutzer ist. Ich habe mich gefragt, ob das ein Zweitaccount der Person ist oder einfach ein Tippfehler bzw. Missverständnis. Edit: Ich habe festgestellt, dass der Großteil des Beitrags aus dem README zitiert ist. Mit > und * als Zitierzeichen wäre das deutlich klarer gewesen. Hier ist der Link zum kentonv-Profil

  • „Ich hielt LLMs für verzierte Markov-Ketten-Generatoren“ und „Ich war überrascht, dass KI ziemlich guten Code erzeugen kann“ widersprechen sich nicht. Ich finde LLMs sehr nützlich, aber ihr Wesen ist weiterhin eher das eines Mustergenerators. Der wichtige Punkt ist, dass das vielleicht bereits ausreicht und Menschen strukturell womöglich gar nicht so anders funktionieren

  • In letzter Zeit bin ich eher skeptischer als pro-AI, aber ich versuche trotzdem weiter, KI in meinen Workflow einzubauen. In der Praxis ist es oft schwerer, etwas zu erklären, sodass es einfacher ist, es direkt selbst zu machen. Es macht auch nicht besonders viel Spaß, aber weil das das Werkzeug der „Zukunft“ sein soll, halte ich es für klug, es zu lernen. Wirklich ausgereiftes AI-Tooling steckt meiner Meinung nach noch ganz am Anfang. Ich bleibe gespannt auf interessante UX-Beispiele in Zukunft

  • Hinweis, direkt im Commit-Verlauf nachzusehen, wie Claude anfangs gepromptet wurde und wie der Code tatsächlich entstand. Es gibt einen Direktlink zur ersten Commit-Seite. Dort gab es viele klare und konkrete Anweisungen, und auch Beispiel-Commit 1 und Beispiel-Commit 2 sind sehenswert

• Auszug aus einem Issue-Commit von Cloudflare workers-oauth-provider. Claude hatte in einem früheren Commit einen Bug eingebaut, und man versuchte mehrmals, ihn per Prompt beheben zu lassen, scheiterte aber immer wieder. Am Ende musste ein Mensch den Fix direkt vornehmen und sogar das OAuth-2.1-Spezifikationsproblem im README dokumentieren. Ich kann das aus meiner eigenen KI-Nutzung sehr gut nachvollziehen. Oft kommt sie bis zur Hälfte gut voran und hat dann mit dem Rest große Schwierigkeiten

  • Auffällig ist, dass KI bis zur Mitte gut arbeitet, aber nach einem Fehler danach alles entgleist. Sobald man einen Fehler entdeckt, muss man den Prompt sofort von ganz vorn neu schreiben und die Unterhaltung neu beginnen. Nach einem einmaligen Fehltritt bleiben die Ergebnisse selbst nach Korrekturversuchen oft falsch. Deshalb muss man alles klar in die richtige Startnachricht packen und von vorne neu erzeugen, damit derselbe Fehler nicht wiederholt wird

  • Solche Probleme lassen sich etwas abmildern, wenn man Tests oder eine klare Spezifikation vorbereitet und die KI dann damit arbeiten lässt. Noch vor ein paar Monaten brauchte KI für solche Spezifikationsrätsel lange, und die Ergebnisse waren qualitativ schlechter als schnelle Antworten. In letzter Zeit sind die Modelle aber deutlich besser geworden, sodass solche Aufgaben ziemlich interessant werden und der Nutzen steigt, wenn sich etwas gut spezifizieren lässt. Für mich persönlich war sonnet 3.7 ein großer Sprung gegenüber 3.5, und Gemini 2.5 Pro war noch beeindruckender. sonnet 4 macht weniger Fehler, aber aus Sicht des Software Engineering muss man die KI weiterhin gut führen, also bei Anforderungsdefinition, Exploration technischer Lösungen, Architekturdesign, User Stories und Spezifikationen sowie beim Schreiben von Code. Zusätzlich lässt sich die Wirkung stark steigern, wenn man gute Beispiele in den Kontext der KI einbringt. Als ich kürzlich mit der OpenAI Realtime API eine App gebaut habe, war es anfangs ein kompletter Fehlschlag, aber nachdem ich zwei Dokumentationsseiten und ein Demo-Projekt in den Workspace gelegt hatte, bekam ich sofort das gewünschte Ergebnis, obwohl ich die API in meinem Fall anders verwenden musste

  • In den Zeilen 163 bis 172 des Commits finden sich Aussagen, die offensichtlich sachlich falsch sind oder je nach A/S-Implementierung unterschiedlich interpretiert werden. Der Authentifizierungsserver von Auth0 hat zum Beispiel eine „leeway“-Einstellung für Netzwerklatenzen, einige andere Authentifizierungsserver sind aber viel strenger. Die Details unterscheiden sich je nach Implementierung, und deshalb glaube ich, dass die Wahrscheinlichkeit, mit nur Standarddokumenten (RFCs) und veröffentlichtem Open Source eine sichere Implementierung durch ein LLM zu erhalten, am Ende trotzdem eine menschliche Prüfung auf einem Niveau erfordert, das einer Eigenimplementierung fast gleichkommt

  • Ich frage mich, ob es langfristige Forschung dazu gibt, ob LLM-basierte Werkzeuge tatsächlich Arbeitsaufwand einsparen oder nur die Illusion von Produktivität erzeugen

  • Für mich zeigt diese Erfahrung, dass AI-Tools nicht wirklich verstehen, sondern auf Basis eines riesigen Musterdatensatzes emergente Ausgaben erzeugen

• Die Zukunft des AI-Coding wird vermutlich nicht die LinkedIn-/X-Fantasie sein, in der Software Engineers verschwinden und ein Businessman nur auf einen Knopf drückt, sondern eher eine Welt, in der erfahrene Ingenieure einen Teil des Codes mit KI erzeugen und ihn dann sorgfältig prüfen und testen. Die eigentliche wichtige Frage ist: „Hätte kentonv diese Bibliothek ohne KI allein schneller bauen können?“

  • Der Bau der Bibliothek mit KI dauerte ein paar Tage. Von Hand hätte es vermutlich mehrere Wochen oder vielleicht sogar Monate gedauert. Allerdings ist das hier ein sehr idealer Fall: klare Standards, klare API-Spezifikationen und eine bereits gut bekannte Plattform. Als versucht wurde, mit KI die Workers Runtime selbst zu verändern, war der Zeitgewinn gering. In Codebasen anderer Leute, mit denen ich weniger vertraut bin, ist KI dagegen wirklich sehr hilfreich. Es ist inzwischen viel leichter geworden, in fremde, komplexe Codewelten einzusteigen, und Dinge, die ich früher eher gemieden hätte, kann ich jetzt selbst relativ einfach ändern

  • Auf die Frage, ob es ohne KI schneller gegangen wäre, würde ich ziemlich klar mit Nein antworten. Mit den Tools, die wir heute haben, und den sich ständig verbessernden Arbeitsweisen wird es in den nächsten 3 bis 6 Monaten wahrscheinlich schneller sein, neue Lösungen direkt mit KI zu programmieren. Wichtig ist aber eine Codebasis, die gut dokumentiert, klar strukturiert und mit schnellen Feedback-Schleifen ausgestattet ist, also guten Lintern und Unit-Tests. In diese Richtung bewegen wir uns

  • Aus meiner Erfahrung muss man von KI erzeugten Code sehr sorgfältig reviewen und testen, und dieser Prozess ist <i>langsamer</i>, als wenn ich den Code einfach selbst schreibe. Deshalb hilft mir KI im jetzigen Zustand nicht besonders. Wie das Sprichwort sagt: Ein schlechter Helfer ist schlimmer als gar kein Helfer. Im Moment ist KI für mich genau so ein „schlechter Helfer“

  • Wenn das Modell „erfahrene Ingenieure erzeugen einen Teil des Codes mit KI und testen ihn dann sorgfältig“ zutrifft, dann fragt man sich am Ende, ob statt 20 kentonvs nicht auch 2 genügen würden. Wird es für die übrigen 18 Leute weiter genug Arbeit geben? Das Beispiel des Autors ist technisch anspruchsvoll, aber ich frage mich, was das für eher unspektakuläre LoB-Apps bedeutet

  • Wenn erfahrene Entwickler nur noch sorgfältig reviewen und testen und Junior-Stellen komplett durch KI ersetzt werden, woher sollen dann künftig die erfahrenen Entwickler kommen? Auch einfache repetitive Arbeit hat aus meiner Sicht ihren Wert

• Es ist an sich schon faszinierend, diese vielen verschiedenen Argumente und Meinungen zu sehen. Danke an Cloudflare, das als führendes Unternehmen im Bereich Internetsicherheit einen Versuch zeigt, die Welt mit einer neuen Form des „Vibe Coding“ zu verbinden. Ich hatte das Gefühl, dass solche KI-Prompts und dieser Code auch anderen Entwicklern mehr Lust auf programmatische Erkundung machen. Vibe Programming war für mich ein sehr bedeutungsvolles Mittel, um aus meiner Niedergeschlagenheit herauszukommen und wieder auf eine Weise zu programmieren, die mir liegt. Ich hoffe, dass diese Erfahrung auch anderen hilft. Ich erwarte, dass sowohl heutige als auch zukünftige Generationen solche Ansätze nutzen werden. Gleichzeitig denke ich, dass wir darüber sprechen sollten, wie diese Arbeitsweise mit psychischer Gesundheit und mentalen Problemen zusammenhängt. Letztlich sollten wir im Blick behalten, dass diese Werkzeuge Hilfsmittel für Menschen sind, und überlegen, wie wir sie so einsetzen, dass wir mit Leidenschaft wachsen können. Ich hoffe, dass es im Open-Source-Bereich noch viele Beispiele geben wird, die nicht nur technische Fähigkeiten, sondern auch logisches und durchdachtes Vorgehen in Projekten zeigen. Noch einmal großes Lob an Cloudflare

• Sammlung typischer Prompt-Austausche. In diesem Beispiel eines Prompt-Transkripts werden sogar die tatsächlichen Kosten offengelegt (insgesamt 6,45 US-Dollar). Verweise gibt es auch auf zugehörigen Commit 1 und Commit 2. Es überrascht mich, dass es so wenige wirklich brauchbare Erfahrungsberichte über AI-Workflows gibt, besonders von erfahrenen Leuten, weil vieles vom Hype überdeckt wird. Mich interessieren echte Live-Coding-Fälle und nicht nur Todo-Listen. Auch die Texte von antirez und tptacek (antirez-Beispiel, tptacek-Beitrag) könnten hilfreich sein

  • Ich habe es nicht exakt nachverfolgt, aber ich schätze die Claude-Kosten insgesamt auf ungefähr 50 US-Dollar. Gemessen an der eingesparten Zeit ist das praktisch vernachlässigbar

• Ich glaube, dass „vibecoding“ am Ende nicht überleben wird. Es braucht weiterhin die Prüfung und das Bugfixing durch exzellente Programmierer, und es gab Bugs, die die KI nicht beheben konnte. Solche Tools sind am Ende eher Beschleuniger für Leute, die die jeweilige Aufgabe ohnehin bereits gut verstehen. Vielleicht gilt das nicht für ganz einfache Homepages, aber Werkzeuge, die so etwas automatisch erzeugen, gibt es schon seit Jahren

  • Vibecoding eignet sich im Moment am besten für Aufgaben mit geringem Risiko. GUI, CRUD-Apps, einmalige Experimente und generell Bereiche, in denen Menschen mit wenig Macht neue Fähigkeiten bekommen, sind sinnvolle Einsatzfelder. Ich würde den vorliegenden Fall eher nicht als Vibecoding, sondern als LLM-assisted coding bezeichnen

  • Tatsächlich wirkt es so, als würde der Begriff Vibecoding oft als Strohmann für Angriffe benutzt. Wenn man Code, den ein LLM erzeugt hat, mit nur kleinen Änderungen übernimmt, ist das dann nicht im Grunde auch schon Vibe Coding?

• Ich bin dem OP sehr dankbar, dass nicht nur der KI-generierte Code, sondern auch die Prompts offengelegt wurden. Ich persönlich kämpfe beim Entwickeln von Nicht-Web-Code mit LLMs immer wieder mit Halluzinationen, aktuell besonders bei .NET-Implementierungen, die per Reverse Engineering SAP ABAP auslesen und Daten in Snowflake überführen. Weil andere oft von Erfolg berichten, dachte ich schon, dass vielleicht nur meine Prompts das Problem seien, aber durch dieses veröffentlichte Beispiel habe ich gemerkt, dass ich damit gar nicht so weit danebenliege. Ich denke, LLMs funktionieren für mich deshalb nicht gut, weil die Probleme, die ich ihnen gebe, etwas seltener und neuer sind. Wenn es nicht wie im veröffentlichten OAuth-Fall ein stark trainiertes Thema ist, kommen LLMs nicht gut mit

• Für diese Art von repetitivem Code, der schon hunderte Male implementiert wurde, ist KI perfekt geeignet. Der gesamte Code umfasst nur etwa 1200 Zeilen und ist damit eher klein. Dass es trotz KI mehr als zwei Tage gedauert hat, überrascht mich sogar eher

• In den letzten Monaten habe ich mit Claude in Cursor an meinem eigenen Greenfield-Projekt gearbeitet und dabei drei Dinge gemerkt: Erstens ist meine Produktivität massiv gestiegen. Zweitens bin ich mental viel erschöpfter als früher. Drittens entwickeln sich die Tools inzwischen selbst in kurzen Zeiträumen extrem schnell weiter, wodurch sich die beiden ersten Effekte noch verstärken

  • Genau das ist auch meine Erfahrung und die anderer Entwickler, mit denen ich gesprochen habe. LLM-assisted coding hilft tatsächlich stark bei der Produktivität, kostet aber entsprechend mehr Energie. Das fühlt sich fast schon merkwürdig an

  • Nachfrage zu diesem „Warum ist man dadurch müder?“. Ich nutze meinen Agenten (Devstral) eher wie beim Pair Programming, und Reviews sind für mich viel leichter, als den gesamten Code selbst zu tippen. Zeitlich ist das ein großer Vorteil. Beim Vibe Coding geht der Kontext der Codebasis verloren, wodurch Review und Einstieg später deutlich schwieriger werden. Beim Pair Programming baut man den Kontext dagegen laufend mit auf, daher empfinde ich Reviews als deutlich schneller

  • Bei mir ist es eher genau umgekehrt. Weil die KI sich um all die kleinen Details kümmert, empfinde ich große Erleichterung. Ich kann mich frei auf übergeordnete Ziele wie Architektur konzentrieren

• Ich finde es ziemlich amüsant, dass ausgerechnet bei einem Unternehmen wie Cloudflare ein „Too Many Requests“-Fehler auftaucht

  • Geht mir genauso