Cloudflare launches self-managed OAuth for all customers

Cloudflare launches self-managed OAuth for all customers

Cloudflare opens OAuth to every customer

Cloudflare’s new self‑managed OAuth feature lets any Cloudflare account create its own OAuth applications, giving developers a standard, revocable, and consent‑driven way to access the Cloudflare API instead of relying on long‑lived API tokens.

Why universal OAuth matters

  • Improved security – Users see a clear consent screen, can revoke access from the dashboard, and are protected from phishing attacks.
  • Better developer experience – Scoped access matches modern SaaS and internal platform workflows, eliminating the need for brittle API‑token management.
  • Ecosystem growth – Opening OAuth removes a barrier for third‑party integrations, agentic tools, and custom automation pipelines.

Scaling the OAuth engine securely

Cloudflare’s original OAuth implementation used the open‑source Hydra engine, which was sufficient for a handful of manually onboarded partners. As the developer platform expanded, the team recognized three critical gaps:

  1. Permissions model – The earlier consent flow did not clearly separate application identity from granted scopes.
  2. Revocation experience – Users could not easily see or revoke app access.
  3. Abuse mitigation – The engine lacked robust safeguards for large‑scale, automated usage.

To address these gaps, Cloudflare updated the consent UI, added dashboard revocation controls, and made app ownership visible to users.

Upgrade strategy for Hydra 1.X → 2.X

Two‑step upgrade plan

  • Step 1 – 1.X migration – Move to the latest 1.X release, rewrite schema migrations to use CREATE INDEX CONCURRENTLY, and replace SELECT * queries with explicit column lists to avoid lock contention.
  • Step 2 – 2.X migration – Deploy a blue‑green architecture to avoid downtime while handling massive schema changes.

Blue‑green migration details

  • Write‑enabled approach – Instead of disabling all writes, Cloudflare extended token TTLs to several hours, allowing existing tokens to remain valid during the cut‑over.
  • Revocation replay queue – A Cloudflare Queue captures revocation events during the migration; after the switch, the queue is drained to replay any missed revocations, preventing accidental re‑grant of access.

Execution outcomes

1.X upgrade

  • Migration completed without user impact.
  • New stricter refresh‑token invalidation caused occasional token‑chain invalidations; Cloudflare mitigated this by adding a refresh‑token coalescing layer in a Worker and leveraging Hydra 2.X’s configurable grace period.

2.X upgrade

  • Migration window selected during lowest request volume; total runtime ~3 hours.
  • Post‑cutover, a data‑cleanup job erroneously purged valid OAuth policy data, leading to a spike in 403 responses. The issue was fixed by restoring data and improving authorization logic.
  • Additional client‑specific tweaks were applied quickly after the rollout.

Performance gains after the upgrade

Metric Before After Δ
API P95 latency 185 ms 101 ms ‑45 %
RSS memory 888 MB 763 MB ‑14 %
Go heap allocation 449 MB 271 MB ‑40 %
Goroutine count 4,015 3,076 ‑23 %
CPU usage 1.07 cores 0.67 cores ‑37 %

Database migration statistics also show the scale of the operation:

  • 132.5 M rows updated
  • 114.7 M rows inserted
  • 136.97 GB temporary storage used
  • 22.2 k transaction commits

Getting started with self‑managed OAuth

Developers can now create OAuth apps directly from the Cloudflare dashboard or via the official documentation:

By enabling any customer to register OAuth clients, Cloudflare paves the way for a richer app ecosystem, tighter security, and smoother integration workflows across the web.

Sources