Cloudflare OAuth für alle Kunden
(blog.cloudflare.com)- Cloudflare ermöglicht es Kunden, eigene self-managed OAuth-Apps zu erstellen und Zugriff auf die Cloudflare API über den standardisierten delegierten Autorisierungs-Flow bereitzustellen
- Bisher konnten nur einige manuell onboardete Partner OAuth von Drittanbietern nutzen; Entwickler eigener Integrationen mussten auf API-Tokens setzen, die nicht gut zu delegierten App-Flows passen
- Für die allgemeine Verfügbarkeit wurden Consent Screen, Widerruf und Anzeige der App-Inhaberschaft verbessert; außerdem wurde die OAuth-Engine Hydra schrittweise von 1.X auf 2.X aktualisiert
- Während des Upgrades traten Schema-Migrationen, Fehler bei der Token-Aktualisierung, das Risiko verlorener Widerrufs-Events und ein Anstieg von 403-Fehlern auf; Cloudflare reagierte mit gleichzeitiger Indexerstellung, einer Queue zum Wiederabspielen von Widerrufen und Datenwiederherstellung
- Nach dem Upgrade sank API P95 von 185 ms auf 101 ms um 45 %, auch die CPU-Auslastung ging von 1,07 Cores auf 0,67 Cores zurück, wodurch die Betriebsbasis für öffentliches OAuth stabilisiert wurde
Erweiterung der öffentlichen Verfügbarkeit von Cloudflare OAuth
- Cloudflare ermöglicht seit Langem Automatisierung, CI/CD und Infrastruktur-Integrationen über Plattform-APIs und macht nun self-managed OAuth für alle Kunden verfügbar
- Cloudflare OAuth selbst ist keine neue Funktion und wurde bereits in Partner-Integrationen wie Wrangler oder PlanetScale genutzt
- Das bisherige OAuth für Drittanbieter stand jedoch nur wenigen manuell onboardeten Integrationen zur Verfügung und war nicht für das breitere Entwickler-Ökosystem geöffnet
- Entwickler, die eigene Integrationen bauen, mussten auf API-Tokens zurückgreifen; dieser Ansatz ist schwer zu verwalten und passt nicht gut zu vielen delegierten Anwendungs-Flows
- Mit self-managed OAuth können Entwickler einen standardisierten OAuth-Flow anbieten, bei dem Kunden selbst scoped Zugriff autorisieren
- Wichtige Anwendungsfälle sind SaaS-Integrationen, interne Developer-Plattformen und Agent-Tools
- Nutzer erhalten klareren Consent, einfacheren Widerruf und mehr Kontrolle über Anwendungsberechtigungen
Sicherheitsbasis für die allgemeine Verfügbarkeit überarbeitet
- Die frühe OAuth-Lösung war für eine kleine Zahl verwalteter Partner ausreichend, aber für die Öffnung gegenüber allen Kunden waren Berechtigungsmodell, Consent-Erlebnis und Mechanismen zur Missbrauchsreduzierung noch nicht ausgereift genug
- Cloudflare verbesserte Anfang des Jahres das Consent-Erlebnis, sodass klarer angezeigt wird, welche Anwendung Zugriff anfordert und welche Berechtigungen sie erhält
- Im Dashboard wurde eine Widerrufsfunktion hinzugefügt, damit Entwickler leichter steuern können, welche Anwendungen auf ihre Daten zugreifen dürfen
- Um OAuth-Phishing-Angriffe zu reduzieren, wurde auch die App-Inhaberschaft besser sichtbar gemacht
- Um self-managed OAuth für alle Kunden zu öffnen, war ein Upgrade der OAuth-Engine erforderlich, das Datenstabilität und Sicherheit bei minimaler Unterbrechung für Nutzer gewährleistet
Vorbereitung des Hydra-1.X-Upgrades
- Cloudflare nutzt seit Langem die Open-Source-OAuth-Engine Hydra als interne Engine für Cloudflare OAuth
- Mit dem Wachstum der Developer-Plattform und mehr Agent-Workflows wurde ein großes Upgrade für neue Funktionen und Performance-Verbesserungen nötig
- Statt ein großes Upgrade auf einmal durchzuführen, wählte Cloudflare einen schrittweisen Ansatz: zuerst auf das neueste 1.X-Release wechseln, anschließend Verhaltens- und Performance-Änderungen bewerten und dann zum 2.X-Upgrade übergehen
- Schon das 1.X-Upgrade konnte potenziell Kunden betreffen
- Die Hydra-Datenbank erstellt Indizes auf wichtige Tabellen mit exklusiven Locks
- Es werden Spalten zu wichtigen Tabellen hinzugefügt und andere Spalten in neue Tabellen verschoben
- Das SDK der verwendeten Hydra-Version führte
SELECT *aus, was bei Schemaänderungen zu Deserialisierungsproblemen führen konnte
- Um Auswirkungen auf Nutzer zu vermeiden, wurden SQL-Migrationen mit Ansätzen wie
CREATE INDEX CONCURRENTLYneu geschrieben und eine angepasste Hydra-Version erstellt, die stattSELECT *explizite Spalten auswählt
Strategie für das Hydra-2.X-Upgrade
- Wegen des Umfangs der Schemaänderungen war ein In-place-Upgrade für das 2.X-Upgrade ungeeignet; Cloudflare entschied sich für eine Blue-Green-Strategie
- Es reichte nicht aus, einfach auf die neue Version umzuschalten
- Upgrade und Migration dauern mehrere Stunden
- Während dieser Zeit musste das System weiterhin korrekt funktionieren
- Die erste Blue-Green-Option bestand darin, Datenbank-Schreibvorgänge zu blockieren und damit neue Autorisierungen zu verhindern
- Neue Schreibvorgänge während der Umstellung gehen nicht verloren
- Nutzer ohne bereits gültige Credentials können bestehende OAuth-Apps nicht verwenden
- Während des Upgrades können Nutzer den Zugriff auf Anwendungen nicht widerrufen
- Die endgültige Strategie bestand darin, Datenbank-Schreibvorgänge beizubehalten, einen gewissen Verlust von Schreibvorgängen in Kauf zu nehmen und das Verlustrisiko zu reduzieren
- Um neue Token-Schreibvorgänge zu reduzieren, wurde die Token-Ablaufzeit auf mehrere Stunden verlängert
- Apps, die vor dem Upgrade Tokens erhalten hatten, können ohne erneute Aktualisierung weiter genutzt werden
- Der Verlust von Widerrufs-Events wurde durch ein Queue-System auf Basis von Cloudflare Queues verhindert
- Wenn ein Widerrufs-Event auftritt, werden die entsprechenden Informationen in die Queue geschrieben
- Nach dem Wechsel auf die Datenbank der Green-Version wird die Queue geleert, um Widerrufe aus dem Upgrade-Fenster erneut abzuspielen
- Falls diese Verarbeitung fehlschlägt, könnte der Zugriff einer vom Nutzer widerrufenen Anwendung unbeabsichtigt wiederhergestellt werden
1.X-Upgrade und Probleme bei der Token-Aktualisierung
- Das erste Upgrade auf das neueste 1.X-Release verlief aus Betriebssicht ohne größere Probleme
- Die angepassten Datenbankmigrationen liefen schneller als erwartet und hatten keine Auswirkungen auf Nutzer
- Da die alte Version von der neuen Version erzeugte Tokens nicht introspektieren konnte, war ein harter Cutover erforderlich
- Nach dem Cutover nahmen zuvor nicht sichtbare Refresh-Token-Fehler zu
- Ursache war das strengere Verhalten der neuen Version bei der Ungültigmachung von Refresh Tokens
- Wird ein Refresh Token erneut verwendet, invalidiert Hydra die gesamte Access-Token- und Refresh-Token-Kette
- Wrangler und MCP-Clients erzeugen viel Traffic, sodass eine einzige Wiederverwendung eines Refresh Tokens die gesamte Session ungültig machen konnte
- Cloudflare fügte dem Worker, der OAuth-Traffic an das richtige Ziel routet, ein Refresh Token Coalescing hinzu
- Refresh-Token-Anfragen werden kurz zwischengespeichert, bevor sie Hydra erreichen
- Wird ein Retry erkannt, wird die Anfrage vorzeitig beantwortet, ohne das Token zu invalidieren
- Hydra 2.X bietet eine konfigurierbare
refresh token grace period, die Refresh-Token-Retries für eine bestimmte Zeit erlaubt, ohne die gesamte Kette zu invalidieren
2.X-Umstellung und Wiederherstellungsprozess
- Cloudflare konnte keine mehrstündige, für Nutzer stark spürbare Unterbrechung akzeptieren und führte daher ein Blue-Green-Upgrade durch
- Die tatsächliche Umstellung erforderte mehr Arbeit als nur das Kopieren der Datenbank und das Ausrollen der neuen Hydra-Version
- Aktivieren der Queue zur Erfassung von Widerrufs-Wiederholungen
- Kopieren der Datenbank und Wiederherstellen auf dem neuen Ziel
- Bereinigen bestehender Daten, die Constraints der neuen Version verletzen
- Gleichzeitiger Cutover des Hydra-Service und zweier zentraler interner Systeme
- Monitoring und Validierung nach dem Cutover
- Das Upgrade-Fenster wurde in eine Zeit gelegt, in der Hydra die niedrigste Anzahl von Requests pro Sekunde hatte, um den Verlust von Token-Schreibvorgängen zu minimieren
- Die Produktionsmigration lief auf der neuen Datenbank abgesehen von einigen Timeout-Anpassungen gut; die reine Ausführungszeit betrug etwa 3 Stunden
- Direkt nach der Traffic-Umstellung zeigte sich, dass ein Datenbereinigungsprozess des Authorization Service übermäßig viele OAuth-Policy-Daten löschte
- Dieser Service hängt von der Hydra Consent Session API ab
- Eine der Hydra-Migrationen beschädigte einen Teil gültiger OAuth-Session-Zustände, wodurch gültige Sessions als ungültig markiert wurden
- Die Inkonsistenz zwischen Hydra und Authorization Service zeigte sich als Anstieg von 403-Fehlern
- Cloudflare minderte die Auswirkungen durch Datenwiederherstellung und begann mit Verbesserungen am OAuth-Autorisierungsverhalten, um die Abhängigkeit von statischen Policy-Daten zu reduzieren
- Weitere kleine Korrekturen aus client-spezifischem Verhalten wurden ebenfalls schnell eingespielt
Performance-Verbesserungen nach dem Upgrade
- Nach Abschluss des Hydra-Versionsupgrades blieb der OAuth-Traffic stabil, und Performance sowie Zuverlässigkeit des Systems für Kunden verbesserten sich
- Die neue Basis ist dieselbe wie für die neuen OAuth APIs, die bereits in Staging validiert wurden, und ermöglichte das Release von self-managed OAuth am 3. Juni
- Wichtige während der Datenbankmigration beobachtete Kennzahlen:
- Aktualisierte Zeilen: 132,5 Mio.
- Eingefügte Zeilen: 114,7 Mio.
- Temporäre Bytes: 136,97 GB
- Transaktions-Commits: 22,2 Tsd.
- Die durchschnittlichen Hydra-Performance-Kennzahlen verbesserten sich nach dem Upgrade insgesamt
- API P95: 185 ms → 101 ms, 45 % weniger
- RSS-Speicher: 888 MB → 763 MB, 14 % weniger
- Go heap alloc: 449 MB → 271 MB, 40 % weniger
- Goroutines: 4015 → 3076, 23 % weniger
- CPU: 1,07 Cores → 0,67 Cores, 37 % weniger
Erste Schritte
- Alle Cloudflare-Kunden können nun eigene OAuth-Anwendungen erstellen und Integrationen auf Cloudflare aufbauen
- Zum Einstieg können sie die Dokumentation lesen oder auf der Seite OAuth apps im Dashboard ihre erste OAuth-App erstellen
1 Kommentare
Hacker-News-Kommentare
Ich bin derjenige, der Ory Hydra gebaut hat. Es freut mich wirklich, diesen Blogpost und die technische Beschreibung zu sehen, und ich hätte nie gedacht, dass diese Software einmal Internetunternehmen auf der ganzen Welt schützen würde
Es ist schön zu sehen, dass Version 2.x in dieser Größenordnung gut funktioniert, und auch die CPU-Auslastung scheint absurd niedrig zu sein
Falls Probleme auftreten, gibt es auch eine schnellere kommerzielle Version. Wenn ihr euch für eigenes OAuth, IAM, ReBAC-Berechtigungen, API-Schlüssel und Agentensicherheit interessiert, findet ihr die Open-Source- und kommerziellen Produkte unter https://github.com/ory und https://www.ory.com/
Ich habe früher das IdentityServer-Framework für dotnet im Self-Hosting betrieben und damit jeden Monat mehrere Milliarden Requests verarbeitet, und OAuth und OpenID Connect in dieser Größenordnung waren faktisch fast ein gelöstes Problem, mit geringem Wartungsaufwand
Es war ein Kerndienst der Organisation und unterlag strengen Compliance-Anforderungen, aber das zuständige Team bestand wahrscheinlich nur aus etwa drei Leuten, und es läuft bis heute gut
Ich konnte nie verstehen, warum es bei diesen Protokollen so viel Verwirrung gibt, und fast jeder Junior Engineer, mit dem ich gearbeitet habe, tat sich schwer damit, sie zu verstehen. Scott Bradys Blog https://www.scottbrady.io/ ist bei diesem Thema eine große Hilfe
Sobald Authentifizierung/Autorisierung ins Spiel kommt, scheint bei Engineers eine grundlegende „Angst“ zu entstehen. Sie sind daran gewöhnt, Probleme zu lösen, aber Authentifizierung/Autorisierung fühlt sich eher wie eine Voraussetzung für diese Problemlösung an und erzeugt dadurch kognitive Kosten
Ganz typisch Cloudflare. Es funktioniert für alle gut und ist nicht besonders teuer, nimmt aber als Folge all dieser Vorteile die zentrale Stellung für alles ein
Ich bin Grant. Ich habe zusammen mit Aeneas den Großteil des 2.0-Migrationscodes geschrieben. Danke an das Cloudflare-Team für den Beitrag
Ich frage mich, ob die Stelle „Bei der Untersuchung fanden wir ein Problem in einer der Hydra-Migrationen, durch das der Zustand einiger gültiger OAuth-Sitzungen beschädigt wurde, woraufhin die Migration diese Sitzungen als ungültig markierte“ sich auf eine der Open-Source-Migrationsdateien bezieht
Ich bin inzwischen nicht mehr an dem Projekt beteiligt, würde aber gern wissen, ob das Upstream bereits behoben wurde
Für den gesamten Kontext müsste zumindest innerhalb des Cloudflare-Ökosystems auch ein Plan für Autorisierungs- und Authentifizierungsflüsse dazugehören, daher habe ich gemischte Gefühle. Es gibt nicht einmal ein GitHub-Beispiel
Trotzdem ist es richtig, dass Cloudflare in die richtige Richtung gestartet ist, aber im Vergleich zur zugrunde liegenden gesamten Ory-Produktpalette liegt noch ein weiter Weg vor ihnen. Ory Kratos kümmert sich um Identität, Login, Registrierung, Wiederherstellung, Multi-Faktor-Authentifizierung usw.: https://github.com/ory
Zum Gesamtumfang sollten meiner Meinung nach auch Nutzerspeicher, SAML und ein Plan für ein Multi-Tenant-Organisationsmodell gehören. Als gutes Beispiel bietet Zitadel https://github.com/zitadel eine Verwaltungs-UI für organisatorische Multi-Tenancy, OIDC/PKCE-Unterstützung usw., und etwas RBAC lässt sich ebenfalls ergänzen
Supabase bietet ebenfalls verwaltete und Open-Source-Authentifizierung: https://github.com/supabase/auth
Abseits von „MCP ist tot, Skills leben ewig“ mache ich mir Sorgen, dass die Pläne, MCP an all das anzubinden und Schlüssel zu rotieren, bald massiv explodieren werden
OAuth 2.0 Dynamic Client Registration (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
Mich würden besonders Meinungen im Kontext von Multi-Tenant-SaaS und eingebetteten KI-Assistenten interessieren
In dem Redirect-Flow, der typischerweise verwendet wird, um MCP an einen Agenten anzubinden, sagt die Spezifikation fast nichts darüber, wie man das sicher macht
Man möchte nicht, dass beliebige Personen Clients mit beliebigen Callbacks registrieren können. Das öffnet Phishing Tür und Tor
Wenn jemand einen Client mit einer bösartigen Callback-URL registriert und dann einen Nutzer dazu bringt, auf einen Link zum Start dieses Flows zu klicken, authentifiziert ein legitimer Identity Provider den Nutzer und gibt anschließend das Access Token an den Angreifer weiter
Die Spezifikation winkt das mit einem initialen Access Token ab, das der Client vor der Registrierung zuerst erhalten soll, aber es fehlen Details, und in einer Situation, in der alle Endnutzer Clients sind, dürfte das kaum funktionieren
Im Idealfall möchte man eine Allowlist für Redirect-Muster definieren und sie auf Ziele wie ChatGPT beschränken. Aber das ist nicht standardkonformes Verhalten, daher haben IAM-Anbieter es nicht eilig
Ich verstehe nicht, was hier die Absicht sein soll. Es gibt kein Szenario, in dem das gut ausgeht. Cloudflare ist fast schon ein Infrastrukturanbieter, und ein Infrastrukturmodell, bei dem irgendein Nutzer die Rechte seines Accounts an einen Drittanbieter-Client delegieren kann, hat ein hohes Missbrauchspotenzial
Wenn ein Unternehmen wie AWS das nicht tut, gibt es meiner Meinung nach einen guten Grund dafür
IAM kann zum Beispiel GitHub Actions, die in einem bestimmten Repository laufen, das Recht geben, Lambda zu aktualisieren
OAuth und Enterprise-Authentifizierung sind vielleicht das Schlimmste, was je erfunden wurde. Wenn man mit der Cloud arbeitet, ist das womöglich der verwirrendste und nervigsten Teil.
Selbst AI-Tools haben ein Jahr gebraucht, nur um grundlegendes OAuth in Headless-Systemen zu handhaben, ohne vorauszusetzen, dass sie einen Browser öffnen können.
Wenn wir schon in all die Authentifizierungs-Kaninchenlöcher großer Cloud-Anbieter hinabsteigen müssen – RBAC/IAM/Workload-Identitäten/Service Accounts und so weiter –, dann wäre es schön, wenn wenigstens für die persönliche Nutzung eine einfache Methode übrig bliebe.
Ein einzelner API-Schlüssel reicht doch. Man hält ihn geheim und widerruft ihn bei Bedarf; es braucht nicht 10.000 Schichten Authentifizierungs-Krempel, die auf allen Ebenen jeder Plattform miteinander verheddert sind.
Ein Albtraum für die Privatsphäre.
Für API-Schlüssel haben wir gerade Ory Talos veröffentlicht (https://github.com/ory/talos). Das ist eine gute Alternative, wenn OAuth2 für den Anwendungsfall überdimensioniert ist.
Es gibt aber auch Anwendungsfälle und Sicherheitsbedenken, die den Einsatz von OAuth2 rechtfertigen. Mit Spezifikationen wie DPoP lassen sich solche Flows sicherer machen.
Der hier vorgestellte Anwendungsfall scheint gut zu OAuth2 zu passen, aber es passt nicht überall. Komplexität macht es schwerer, ein System sicher zu halten.
Der Vorteil von OAuth2/OIDC ist, dass das Vertrauen nicht beim Inhaber des API-Schlüssels liegt, sondern bei der tatsächlichen Identität, die Zugriff braucht.
Dass Authentifizierung schwierig ist, gilt für Authentifizierung für viele Nutzer. Authentifizierung nur für einen selbst ist sehr einfach, und mit einem ordentlichen Framework wird es noch leichter.
Wenn du dir bei der Implementierung unsicher bist, wirf sie einem der neueren Modelle vor. Die sind ziemlich gut darin, Probleme in so einfachen Authentifizierungssystemen zu finden.
„Ory Enterprise License: Schaltet Enterprise-Funktionen frei wie CVE-Sicherheits-SLA, SAML, B2B-Organisationen, Multi-Tenancy und bessere Skalierbarkeit“ [0]
Oder man verwendet einfach weiter Keycloak, das ein vollständig selbst hostbares Produkt anbietet [1].
[0]https://github.com/ory
[1]https://www.keycloak.org/
Dass es eine kommerzielle Version gibt, liegt an der Frage, wie man Open Source auf Weltklasse-Niveau finanziell nachhaltig macht. Dass es ein funktionierendes Geschäftsmodell für Open Source gibt, das die größten Softwareunternehmen der Welt trägt, ist nichts Schlechtes, sondern etwas Gutes.
Nur als Hinweis: IBM hat auch einen Weg gefunden, mit Keycloak Geld zu verdienen.
Das hier ist im Grunde eine Diskussion über OAuth für den Zugriff auf Cloudflare-Konten, nicht über eine von Cloudflare gehostete allgemeine „Login“-Funktion für benutzerdefinierte Apps.
Ich dachte, ich hätte verstanden, was OAuth ist, aber dieser Artikel verwirrt mich. Ich hatte es als standardisiertes Protokoll verstanden, das client-spezifische Zugriffsschlüssel bereitstellt.
Was ist hier mit selbstverwaltetem OAuth gemeint? Es braucht eine Erklärung, worauf Zugriff gewährt wird, wer der Client ist und wer der Partner ist.
Es erlaubt dir, selbst ein OAuth-System zu hosten, das den Zugriff auf eigene Ressourcen erlaubt oder verweigert. Statt darauf zu warten, dass Cloudflare unter Bedingung X Y erlaubt, kannst du die gewünschte Logik selbst bauen.
Im Kern ist der Flow: „Bei Cloudflare anmelden“ → Cloudflare prüft die Verwendung von selbstverwaltetem OAuth → Weiterleitung zu deinem OAuth → Cloudflare vertraut der Antwort → wenn der Nutzer zustimmt, wird der Kontozugriff gewährt.