Cloudflare opens up OAuth for third-party integrations

Cloudflare has provided third-party OAuth access to its API for years—Wrangler and partner integrations like PlanetScale have relied on it. But access was limited to a small set of manually onboarded integrations. Developers building their own tooling had to fall back on API tokens, which are unwieldy for delegated application flows and harder for end users to manage and revoke.

That changes with self-managed OAuth, now available to all Cloudflare customers. Any developer can create OAuth clients that let users grant scoped access to their Cloudflare account through a standard authorization flow. The model is aimed at SaaS integrations, internal developer platforms, and agentic tools, where per-user consent and revocation matter more than long-lived tokens.

Before opening OAuth to everyone, Cloudflare had to tighten the surrounding experience. An earlier update improved the consent screen so it is clearer which application is requesting access and what permissions it will receive. Revocation is now available from the dashboard, and app ownership is more visible to reduce the risk of OAuth phishing. On top of that, the underlying OAuth engine needed a major upgrade to handle broader usage.

Planning a two-step engine migration

Cloudflare OAuth has been powered by Hydra, an open-source OAuth engine. The original deployment worked when usage was limited, but growth in the developer platform and the rise of agentic workflows demanded a newer version. Cloudflare planned two sequential upgrades rather than one big jump: first to the latest 1.X release, then to 2.X.

The 1.X upgrade alone was disruptive. Hydra's database migrations would create indexes that lock critical tables exclusively, preventing active users from performing OAuth operations, and would add columns to critical tables while moving others to new tables. A quirk in the old Hydra SDK compounded the problem: it executed SELECT * queries, which would fail deserialization once the schema changed.

Cloudflare rewrote the SQL migrations to use CREATE INDEX CONCURRENTLY and built a custom Hydra version that selects explicit columns instead of using SELECT *. The 1.X cutover itself ran clean and faster than expected, with no user impact. A hard cutover was required because the old version could not introspect tokens created by the new one.

Refresh token retries needed a workaround

After the 1.X cutover, refresh token errors increased. The newer Hydra version invalidates the entire access and refresh token chain if a refresh token is reused. That behavior is a problem for high-volume clients like Wrangler and MCP clients, where a single retried request can kill a whole session.

Cloudflare mitigated this in the Worker that routes OAuth traffic by adding refresh token coalescing: the Worker briefly caches a refresh request, and if it detects a retry, responds without forwarding to Hydra. The later 2.X versions offer a configurable "refresh token grace period" that solves the problem natively.

The blue-green path to Hydra 2.X

The jump to 2.X brought a much larger set of schema changes. An in-place upgrade was out of the question, and the migration would take multiple hours, so Cloudflare chose a blue-green strategy. Two options were considered:

  • Disable database writes during the window—safe, but no new authorizations and no revocations possible until the switch completes.
  • Leave writes enabled and accept some lost writes, offsetting the risk by extending token expiry to multiple hours so apps can operate without refreshing.

Cloudflare chose the second option. To prevent lost revocations, a queue system built on Cloudflare Queues recorded every revocation event during the upgrade window. Once the green database was live, the queue was drained and revocation events replayed, ensuring no revoked application regained access.

Execution and fallout

The production migration ran in roughly three hours. As the rollout unfolded, an overeager data cleanup job in the authorization service started purging valid OAuth policy data. A Hydra migration had corrupted the state of some valid OAuth sessions—marking them invalid—which caused a disagreement with the authorization service and a spike in 403 responses. Cloudflare restored data and began reworking OAuth authorization behavior to reduce reliance on static policy data.

Smaller fixes followed, driven by specific client behaviors. Once traffic stabilized, the upgraded system showed measurable performance gains in both database operations and Hydra request handling, and production was aligned with the foundation that newer OAuth APIs had already been validated against in staging.

Self-managed OAuth is live

Cloudflare self-managed OAuth is now available to all customers. Developers can create OAuth applications and build integrations on top of the Cloudflare API. Documentation is available on the Cloudflare fundamentals site, and the OAuth apps page is live in the dashboard.