Cloudflare öffnet sein OAuth-Ökosystem für alle Kunden, unter dem Namen Self-managed OAuth. Unternehmen und Entwickler können nun eigene OAuth-Anwendungen anlegen, die auf ihr Cloudflare-Konto zugreifen dürfen, und damit Integrationen auf Basis der Cloudflare-API bauen. Bislang stand Third-Party-OAuth nur für wenige, manuell zugelassene Partner zur Verfügung. Wer eigene Anbindungen entwickeln wollte, musste meist auf API-Tokens ausweichen, die für delegierte Zugriffe oft weniger geeignet sind und sich schlechter verwalten lassen.

OAuth ist ein Standard, mit dem eine Anwendung im Namen eines Nutzers auf begrenzte Ressourcen zugreift, ohne dessen Passwort zu erhalten. Das Verfahren nutzt Zustimmungsdialoge, begrenzt Berechtigungen (Scopes) und ermöglicht es Anwendern, erteilte Zugriffe zentral zu widerrufen.

Mehr Kontrolle für Entwickler und Anwender

Cloudflare begründet in seinem Blog die Öffnung mit dem gewachsenen Bedarf der Entwicklerplattform. Da immer mehr Kunden Integrationen, Automatisierungen und agentische Werkzeuge nutzen, ist ein delegierter Zugriff für SaaS-Anbindungen und interne Entwicklerplattformen wichtiger geworden.

Parallel zur Öffnung hat Cloudflare die Sicherheits- und Verwaltungsfunktionen ausgebaut. Dazu gehören ein präziserer Zustimmungsdialog, eine bessere Sichtbarkeit der App-Inhaberschaft zur Abwehr von Phishing sowie eine zentrale Widerrufsfunktion im Dashboard.

Aufwendiger Umbau im Hintergrund

Die Freigabe erforderte tiefgreifende Änderungen an der OAuth-Infrastruktur. Cloudflare setzt weiterhin auf die Open-Source-Engine Hydra, musste jedoch auf eine neuere Version migrieren. Der Anbieter teilte den Umbau in zwei Schritte auf: erst ein Upgrade auf die aktuelle 1.x-Reihe, danach der Wechsel auf 2.x.

Das erste Upgrade brachte technische Hürden mit sich. Die Datenbankmigrationen hätten Tabellen zeitweise exklusiv gesperrt und damit laufende OAuth-Operationen blockiert. Cloudflare passte deshalb die SQL-Migrationen an, nutzte CREATE INDEX CONCURRENTLY und änderte die Abfragen der Hydra-SDKs, um deserialisierungsanfällige SELECT *-Operationen zu vermeiden.

Für den größeren Sprung auf 2.x wählte Cloudflare ein Blue-Green-Verfahren. Dabei lief die neue Version auf einer Kopie der Produktionsdatenbank parallel. Erst nach Abschluss der Migration schaltete der Betreiber um. Um Datenverlust während der Übergangsphase zu verhindern, fing Cloudflare Widerrufe über eine Queue ab und spielte diese nach dem Umschalten in die neue Umgebung zurück.

Token-Verhalten und Migrationseffekte

Nach dem Wechsel auf 1.x registrierte Cloudflare vermehrt Fehler bei Refresh Tokens. Die Ursache lag in einem strengeren Verhalten der neuen Version: Wurde ein Refresh Token erneut verwendet, invalidierte Hydra die gesamte Kette aus Zugriffs- und Refresh-Token. Dies betraf insbesondere Clients mit hoher Anfragefrequenz wie Wrangler und MCP-Clients. Cloudflare fing dies vorübergehend in einem Worker ab, der den OAuth-Verkehr weiterleitet: Doppelte Refresh-Versuche werden dort kurz gepuffert und nicht an Hydra durchgereicht.

Auch der Wechsel auf 2.x verlief nicht völlig reibungslos. Ein Bereinigungsjob im Autorisierungsdienst löschte OAuth-Policy-Daten zu aggressiv. Ursache davon war eine fehlerhafte Hydra-Migration, die den Zustand gültiger Sitzungen beschädigte. Dies führte zu abweichenden Bewertungen zwischen Hydra und dem Autorisierungsdienst, was sich in gehäuften 403-Fehlern äußerte. Cloudflare spielte daraufhin Daten zurück und optimierte das Autorisierungsverhalten.

Mit dem Abschluss der Migration läuft der OAuth-Verkehr nach Angaben des Unternehmens stabiler und performanter. Das Live-System basiert nun auf derselben Grundlage wie die neueren OAuth-APIs, die Cloudflare bereits zuvor in der Staging-Umgebung validiert hatte. Kunden können jetzt ohne Sonderfreigabe eigene OAuth-Apps anlegen und Integrationen auf dieser Basis entwickeln.

(fo)