On June 3, 2026, Cloudflare opened self-managed OAuth to every customer, ending a partner-only arrangement that had limited delegated access to its API to a handful of manually onboarded integrations. Three weeks later, an engineering retrospective explained the zero-downtime Hydra upgrade that made it possible: 132.5 million rows migrated, 114.7 million inserted, and a 45% cut in API P95 latency.
What launched, and when?
Self-managed OAuth clients went generally available on June 3, 2026, with the technical backstory following in a June 24 retrospective. The two dates are worth keeping straight: the first is when any Cloudflare customer could start creating OAuth clients; the second is when Cloudflare explained the engine work behind it.
Before this, OAuth access to Cloudflare accounts was restricted. Wrangler and partners like PlanetScale used it, but only through manually onboarded integrations. Everyone else fell back to API tokens, which are harder to manage and a poor fit for delegated application flows where a third party acts on a user’s behalf.
Now any customer can create an OAuth client from Manage account > OAuth clients in the dashboard. Clients start private, usable only within the creating account. Making a client public, so any Cloudflare user can authorize it, requires verifying the client domain; verified apps show a badge on the consent screen. Scopes mirror the API token model, so developers already comfortable with token scopes can request only what they need.
How did Cloudflare migrate without downtime?
Cloudflare moved its OAuth engine, Hydra, from 1.X to 2.X, migrating 132.5 million database rows and inserting 114.7 million more without taking production OAuth offline, according to the retrospective and ByteIota’s analysis of it. Hydra is the open-source OAuth engine Cloudflare has run for years; it held up at low volume but needed a major upgrade to support new capabilities as agentic workflows increased demand.
Standard Hydra migrations claimed exclusive locks on critical database tables, the kind of lock that would have blocked all active OAuth operations during the upgrade. Cloudflare rewrote the migrations to use non-locking patterns to sidestep this.
The 1.X engine’s strict refresh-token reuse behavior was silently breaking high-volume clients like Wrangler and MCP: a single reused refresh token invalidated the entire access and refresh chain. The fix was token coalescing at the Cloudflare Worker layer, so concurrent refresh requests returned the same token rather than invalidating the chain.
The production cutover ran for roughly three hours. During that window, Cloudflare Queues buffered all revocation events to prevent data loss. Migrating an OAuth engine live means keeping the revocation path intact even when the backing store is in flux; buffering those events into a queue and replaying them after cutover is how Cloudflare avoided silently re-authorizing apps a user had revoked.
How much faster is OAuth after the upgrade?
After the 2.X cutover, OAuth API P95 latency dropped from 185ms to 101ms, a 45% reduction, according to ByteIota’s summary of the retrospective. ByteIota’s coverage also references further resource reductions, including CPU usage, though the cached text truncates before the specific figures, so those numbers are not reproduced here. These are post-upgrade measurements, not sustained SLA figures, so treat them as point-in-time improvements rather than a guaranteed steady state.
The latency cut is the headline a developer feels; the broader resource reduction is what makes opening OAuth to all customers economically tolerable as the client count grows.
What can developers build with self-managed OAuth?
Self-managed OAuth targets three integration categories: SaaS products that act on a customer’s Cloudflare account, internal developer platforms, and agentic tools that need delegated, revocable access.
The dividing line against API tokens is straightforward. API tokens suit personal automation and CI/CD pipelines where the credential owner and the actor are the same party. OAuth is the right choice when a third party needs to act on a user’s Cloudflare account, because it gives the user a consent screen, scoped permissions, and a revocation path that doesn’t require rotating a shared secret.
The agentic angle is where this gets interesting. Self-managed OAuth extends OAuth-based delegated access to third-party developers building agentic tools. Separately, Cloudflare Access already supports managed OAuth for internal apps, letting agents discover authentication via RFC 9728 (OAuth Authorization Server Metadata) and complete a standard OAuth 2.0 flow with PKCE. The two pieces cover the two directions an agent needs: calling out to Cloudflare, and being called from a Cloudflare-fronted app.
Is this a replacement for Auth0 or Okta?
No. Self-managed OAuth makes Cloudflare an authorization server for access to its own API; it does not make Cloudflare a general-purpose identity provider for arbitrary applications. The distinction matters because the two solve different problems.
Auth0 and Okta sit in front of your application and issue identity assertions about your users. Cloudflare’s self-managed OAuth sits in front of Cloudflare’s API and issues access tokens for Cloudflare resources. A SaaS vendor looking for tenant-level SSO for its own user base would not get that from this launch. That adjacent use case belongs to Cloudflare Access, which already supports managed OAuth for internal apps and occupies an identity-proxy role rather than an authorization-server role for Cloudflare’s API.
So any framing that positions OAuth-for-all as a head-on Auth0/Okta competitor overstates the product. The real competitive pressure is narrower and more specific: for integrations that previously needed a manually brokered partnership with Cloudflare to get OAuth, the partner gate is gone.
Where does the lock-in move?
The dependency that has historically bound a customer to Cloudflare is DNS and bandwidth. Self-managed OAuth adds a third axis: the consent and revocation graph for integrations that access a customer’s account.
This is a real but bounded shift. When an integration relies on Cloudflare OAuth, its scopes, consent records, and revocation state live in Cloudflare. Migrating that integration away means re-establishing consent with every end user, because the tokens and their revocation semantics are Cloudflare’s. That said, the lock-in is specific to integrations targeting Cloudflare resources, where the dependency on Cloudflare already exists by definition. The more expansive identity-lock-in argument, where Cloudflare becomes the session authority for SaaS apps generally, depends on adoption of the separate Access identity proxy, not on self-managed OAuth alone.
The honest read: this launch deepens the coupling for integrations that were already coupled, and it does so by giving developers a standards-based OAuth flow rather than a proprietary one. The lock-in is real; the terms of it are unusually open.
What should practitioners watch for?
The launch is generally available, but public OAuth apps require domain verification, and the engine migration that enabled it surfaced real concurrency bugs in production, including refresh-token reuse that broke high-volume clients like Wrangler and MCP.
For practitioners evaluating this now: private clients are available immediately to any account and are sufficient for internal tooling. Public clients, the ones any Cloudflare user can authorize, require verified domain ownership before they show the trust badge users expect on a consent screen. For CI/CD and personal automation, API tokens remain the simpler choice; reach for OAuth when a separate party, human or agent, needs delegated access.
The agentic path is the one most likely to surface rough edges first. RFC 9728 discovery plus PKCE is the mechanism agents use against Access-protected apps; self-managed OAuth is the mechanism for agents calling Cloudflare. If you’re building in that space, instrument token-refresh behavior explicitly. The Wrangler and MCP refresh-token invalidation issue Cloudflare hit is the class of bug that manifests as silent session loss under concurrency, and it’s exactly what you’d want to catch before your users do.
Frequently Asked Questions
Can self-managed OAuth authenticate users for a non-Cloudflare SaaS product?
No. Self-managed OAuth makes Cloudflare the authorization server for its own API, so it issues tokens for Cloudflare resources, not identity assertions for arbitrary applications. For tenant-level SSO on your own app you would still use a general-purpose identity provider, while Cloudflare Access can act as an identity proxy for internal apps using RFC 9728 discovery and PKCE.
How is the OAuth engine migration different from a standard database upgrade?
Standard Hydra migrations take exclusive locks on critical tables, which would have blocked live OAuth traffic. Cloudflare rewrote them to use CREATE INDEX CONCURRENTLY, shipped a custom Hydra build to avoid a SELECT * deserialization issue, and buffered revocation events in Cloudflare Queues during the roughly three-hour cutover, preserving the revocation path while the backing store was rewritten.
What should a team instrument before shipping an agent that refreshes Cloudflare OAuth tokens concurrently?
Monitor token-refresh concurrency and revocation replay closely. The migration exposed a bug where reused refresh tokens invalidated the whole access-and-refresh chain for high-volume clients like Wrangler and MCP; without concurrency-aware logging, that failure appears as silent session loss. For single-owner automation or CI/CD, an API token is usually simpler and avoids the refresh race entirely.
What hidden cost should teams budget for when planning a public OAuth integration?
Beyond the upfront domain verification, every authorized user adds consent, token, and revocation state that lives inside Cloudflare. If you later move the integration away, you must rebuild that state and re-authorize each user, so exit cost rises with adoption. Private internal clients keep that surface much smaller.
