Cloudflare opens OAuth to all developers

Cloudflare has made its OAuth infrastructure available to all customers, removing the need for manual onboarding and enabling developers to create their own OAuth clients for delegated access to the Cloudflare API. The change allows for standard OAuth flows where users grant scoped permissions directly, simplifying the development of SaaS integrations, internal platforms, and agentic tools while improving consent visibility and revocation controls.

Until now, third-party OAuth access was limited to a small group of partners, forcing most developers to rely on API tokens for integrations. Tokens present management challenges and lack the granularity of OAuth for delegated workflows, particularly as demand for agentic tools grows. The shift to self-managed OAuth addresses these limitations while expanding the ecosystem for Cloudflare’s platform, which supports roughly 20% of the web.

Scaling OAuth securely

The expansion of OAuth access required significant upgrades to Cloudflare’s underlying infrastructure. The company’s earlier OAuth implementation, built on the open-source Hydra engine, was designed for a limited number of partners and lacked the maturity needed for broader adoption. Key improvements included a redesigned consent experience to clarify permission requests, dashboard-based revocation controls, and enhanced visibility of app ownership to mitigate phishing risks.

The backend upgrade process was split into two phases: first migrating to the latest 1.X release of Hydra, then proceeding to 2.X. The 1.X upgrade alone involved extensive schema changes, including new indexes and column migrations that risked locking critical tables and disrupting active users. To avoid downtime, Cloudflare rewrote the SQL migrations to use concurrent indexing and modified Hydra to avoid SELECT * operations, which could cause deserialization issues with the new schema.

Upgrade challenges and execution

The 2.X upgrade presented even greater complexity. An in-place migration was ruled out due to the volume of schema changes, leading Cloudflare to adopt a blue-green deployment strategy. However, the multi-hour cutover period introduced risks: disabling writes would prevent new authorizations and revocations, while enabling writes risked data loss during the transition.

To mitigate these issues, Cloudflare implemented two key solutions. First, it increased token expiry times to reduce the frequency of refresh requests during the upgrade window. Second, it built a queue system using Cloudflare Queues to capture revocation events, allowing them to be replayed after the database cutover. This ensured that revoked access would not be inadvertently restored.

The 1.X upgrade proceeded smoothly, with custom migrations completing faster than expected. However, post-upgrade testing revealed a new issue: stricter refresh token invalidation in Hydra 1.X caused session disruptions for high-volume clients like Wrangler and MCP. Cloudflare addressed this by adding refresh token coalescing to its OAuth routing Worker, caching retry requests to prevent invalidation of entire token chains. The 2.X upgrade, which includes a configurable refresh token grace period, is expected to resolve this issue permanently.

Impact for developers

The availability of self-managed OAuth clients removes a key barrier for developers building integrations with Cloudflare’s platform. By standardizing delegated access, the change simplifies workflows for SaaS providers, internal tooling, and AI-driven automation. Users gain clearer consent controls and easier revocation, reducing the risk of unauthorized access.