Democratizing the Cloudflare Ecosystem: Self-Managed OAuth for Everyone

Date: 2026-06-24
Authors: Sam Cabell, Mike Escalante, Adam Bouhmad, and Nick Comer
Read Time: $\approx 6$ minutes

Cloudflare currently supports the infrastructure for roughly 20% of the entire internet, but this is a collaborative effort.

Our users rely on a diverse array of external tools and services. To facilitate this, Cloudflare provides a robust API that allows developers to build the "glue" for their infrastructure via CI/CD pipelines, custom automations, and deep integrations.

The Evolution of Delegated Access

Recently, we introduced self-managed OAuth. This feature empowers customers to create and oversee their own OAuth clients, granting delegated access to the Cloudflare API without compromising security.

While users of Wrangler or partners like PlanetScale have already experienced this, it was previously a gated feature. Third-party OAuth was restricted to a few manually onboarded partners.

API Tokens vs. OAuth

Before this launch, most developers had to rely on API tokens. Here is how the two compare:

Feature	API Tokens	Self-Managed OAuth
Management	Manual/Difficult	Standardized Flow
Access	Static/Broad	Scoped/Granular
User Experience	Poor for delegated apps	Seamless consent screens
Revocation	Manual token deletion	Centralized dashboard control

As the demand for agentic tools and internal developer platforms grew, it became evident that opening OAuth to all users was a prerequisite for the platform's success.

Strengthening the Security Perimeter

Scaling OAuth to a global user base required more than just opening a switch; it required a mature security model. We focused on three primary areas:

• Enhanced Consent: Users now see exactly which application is requesting access and the specific permissions involved.
• Centralized Revocation: A new dashboard allows users to instantly kill access for any application.
• Ownership Visibility: Improved transparency regarding app ownership to mitigate the risk of OAuth-based phishing.

Engineering the Engine Upgrade

To power this, Cloudflare utilizes Hydra, an open-source OAuth engine. While Hydra served us well initially, the shift toward agentic workflows necessitated a performance and capability boost.

The Migration Strategy

We opted for a phased approach rather than a single "big bang" migration:

Phase 1: The 1.X Transition

The move to 1.X was surprisingly complex due to database schema migrations. We encountered issues where:

1. Index creation would trigger exclusive locks on critical tables, blocking active users.
2. Columns were being moved or added to vital tables.
3. The Hydra SDK used SELECT * queries, which broke when the schema changed.

The Fix: We rewrote SQL migrations to use CREATE INDEX CONCURRENTLY and developed a custom Hydra fork to replace SELECT * with explicit column naming.

Phase 2: The 2.X Leap

The 2.X upgrade was even more substantial. An in-place upgrade was impossible due to the volume of schema changes. We considered a Blue-Green deployment, but faced a dilemma: the migration would take several hours.

If we disabled writes during this window:

• $\text{New Authorizations} = 0$
• $\text{Revocations} = \text{Impossible}$

To avoid this, we implemented a strategy to keep the system live:

1. Reducing Write Pressure: We increased token expiry times to several hours. $\text{Token Life} \uparrow \implies \text{Refresh Requests} \downarrow$
2. Ensuring Revocation Integrity: We couldn't afford to lose a "revoke access" request. We built a custom queue system using Cloudflare Queues.

// Conceptual logic for the revocation queue
if (event === 'REVOKE_ACCESS') {
    writeToCloudflareQueue(revocationRecord);
    // Ensure record is processed after Green environment is live
}

By buffering these critical events, we ensured that security actions were preserved even during the transition to the new engine.

---

Contributors: