Cloudflare opened OAuth to every developer on its platform

Cloudflare just made OAuth available to every developer on its platform. The feature, called self-managed OAuth, lets any app build a proper “Connect your Cloudflare account” button instead of asking people to paste in a long-lived API token. Until the June 3 rollout, that flow was reserved for a short list of partners Cloudflare approved by hand.

That sounds like plumbing. It matters because of who needs it now. SaaS tools that manage your DNS, internal platform teams that deploy on your behalf, and the wave of AI agents that want to touch your Cloudflare account all need a way to act as you without becoming you. A pasted API token does that badly. OAuth does it the way the rest of the web already expects, and Cloudflare just handed the primitive to everyone.

What OAuth actually solves

Start with the problem, because OAuth is one of those words people nod along to without a clear picture. Say you use a third-party dashboard to manage your Cloudflare DNS. The dashboard needs permission to read and edit your records. How does it get that permission?

The crude answer is: you generate a credential and hand it over. On Cloudflare that meant creating an API token in your dashboard, choosing some permissions, copying the string, and pasting it into the other app. It works. It’s also a small disaster waiting to happen. The token usually does not expire on its own. People over-grant it because picking exact permissions is fiddly. And if you want to cut off one app later, you have to remember which token you gave it and revoke that specific one.

OAuth replaces the paste with a redirect. You click “Connect,” Cloudflare shows you a consent screen listing what the app wants, you approve, and the app receives a token scoped to exactly those scopes. No password changes hands. The app never sees your login. You can revoke its access from one place without touching anything else. This is the same dance you do when a site offers “Sign in with Google,” just pointed at your Cloudflare account instead.

The reason developers dread building this is that the protocol is genuinely finicky. Redirect URIs, token refresh, PKCE, consent screens, secure storage of secrets: every step has a sharp edge, and getting one wrong is a security bug, not a typo. One Hacker News commenter put the mood bluntly, calling enterprise auth “the most confusing and frustrating part of dealing with the cloud.” That frustration is exactly why people reach for the API-token shortcut and why a platform offering OAuth as a built-in feature is worth noticing.

What Cloudflare opened up

Here’s the precise change, because it’s easy to overshoot it. Cloudflare did not ship a hosted login product for your app. What it opened is OAuth into Cloudflare’s own API. Any developer can now create what Cloudflare calls a self-managed OAuth client, register it in the dashboard under Manage account, pick the scopes it needs, and send users through a real consent flow to grant access to their Cloudflare account.

Cloudflare frames the whole point as unlocking its app ecosystem: “developers can now offer a standard OAuth flow where customers grant scoped access directly, making it easier to build SaaS integrations, internal developer platforms, and agentic tools.” Scope selection works like API tokens, so the mental model carries over. An app starts private, visible only to your own account members, and you have to verify a domain before you can make it public.

The interesting tell is the third use case: agents. Cloudflare’s own MCP servers already speak OAuth 2.1, and the company is explicit that the surge in demand for delegated access came from agentic tools. An AI agent that deploys a Worker on your behalf is the textbook case for OAuth. You want it to have a token that does one job, that you approved on a screen you read, and that you can yank the second it misbehaves. A shared API key gives you none of that.

Why it took this long

If OAuth is so obviously the right model, why was it partner-only for years? Cost and risk. Running an OAuth provider at the scale of a company that sits in front of a fifth of the web is not a weekend project. Every new client is a new trust relationship, a new consent surface, and a new way for things to go wrong. Gating it to vetted partners kept the blast radius small while the platform was young.

What changed is the engine underneath. Cloudflare moved its OAuth backend onto Hydra, the open-source OAuth and OpenID Connect server from Ory, and rebuilt the surrounding machinery on its own stack. Workers route the OAuth traffic. Cloudflare Queues track revocation events during the migration so a token that should be dead does not linger. The team even called out a subtle fix: coalescing refresh-token requests so that a client retrying a refresh does not accidentally invalidate its own session, a failure mode that bites MCP clients in particular. Ory’s founder got a warm nod on Hacker News, where one developer wrote that “Ory services are a delight.” Building on a battle-tested engine is what made opening the gate safe.

The catch worth knowing

The honest limitation is the one the headline can blur. This is delegated access to Cloudflare, not authentication for your app. If you are building a product and you want users to log into it, self-managed OAuth is not that. The companies you would reach for there are Auth0, Okta’s customer-identity line, Clerk, and the rest of the managed-auth market. They host the login, the user store, and the consent UI for your service. Cloudflare’s new feature does the opposite direction: it makes Cloudflare the identity provider and your app the client.

Cloudflare does have an answer for the build-your-own-provider case, but it’s a separate tool. The workers-oauth-provider library wraps your Worker and implements the provider side of OAuth 2.1, including PKCE, dynamic client registration, and the metadata endpoints, so you can stand up your own OAuth server for the apps and agents that connect to you. It’s open source, it’s young, and it’s the piece that actually overlaps with what people mean when they say “auth is painful to build.” Two different products, one umbrella push: Cloudflare wants OAuth to be the default way anything talks to anything on its platform, agents very much included.

There’s also a quieter concern raised in the discussion thread: centralization. An OAuth provider sees which apps you connect and when. The more roads run through one company, the more that company sees and the harder it is to leave. Cloudflare ships these features cheaply and well, which is exactly what makes the gravity strong. Worth keeping in view, even as you click “Connect.”

What this means for you

If you build anything that touches Cloudflare accounts, this is a real upgrade and you should plan to use it. Swap the “paste your API token” step for an OAuth flow: your users get a consent screen they understand, least-privilege scopes, and one-click revocation, and you stop being the app that asked them to hand over a god-mode credential. If you ship MCP servers or agents, treat OAuth as the default delegated-access model now rather than retrofitting it later. But keep the two products straight. Self-managed OAuth connects apps to Cloudflare; if you need login in your own app, reach for workers-oauth-provider or a hosted identity service, and budget the time, because that side is still the hard part.