Cloudflare opens self-service OAuth to every developer

For years, if you wanted your app to touch someone else's Cloudflare account, you had two paths. Be one of a handful of partners Cloudflare manually onboarded for OAuth (the Wrangler CLI, PlanetScale, a few others), or tell your users to mint a long-lived API token and paste it into your service. The first was a closed door. The second is exactly the pattern security teams have spent a decade trying to kill.

That door is now open. Cloudflare has rolled out self-managed OAuth clients to all developers, letting anyone register an OAuth application, request a set of scopes, and send users through a standard consent flow to grant delegated access to the Cloudflare API. It's a small-sounding changelog entry with a large blast radius, and the more interesting story sits underneath it: a multi-hour, near-zero-downtime upgrade of the OAuth engine that powers all of this, and a clear bet that agentic tooling is about to make delegated access table stakes.

API tokens were never the right tool for this

API tokens solve a real problem: machine-to-machine auth where one party owns both ends. They're a poor fit for the delegated case, where a third-party app needs to act on behalf of a user. The token is a bearer secret with no built-in notion of who granted it, what it's really for, or how a user revokes it without breaking everything else. In practice it ends up copied into a config, an env var, a CI secret, and a vendor's database, where it sits until someone rotates it (nobody rotates it).

OAuth clients flip the model. You register an application in Manage account > OAuth clients, pick the minimum scopes you need (Cloudflare notes the scope picker mirrors the API token permissions you already know), and at runtime you redirect the user to Cloudflare to approve exactly those scopes. Your service never sees the user's standing credentials, only a scoped, refreshable token tied to a consent record the user can pull back at any time from the dashboard.

The practical wins are the usual OAuth wins, but they land differently when the platform in question fronts roughly a fifth of the web:

• Scoped consent. Users see which app is asking and what it can do before they say yes, instead of being told to generate a token with whatever permissions the integration's docs demand.
• First-class revocation. Killing one app's access no longer means rotating a secret that five other things depend on.
• Ownership and anti-phishing signals. Apps can go from private (usable only within the account that created them) to public, but public visibility requires domain verification, which puts a verified badge on the consent screen so users can tell a real vendor from an impostor harvesting OAuth grants.

None of this is novel as a concept. GitHub Apps, Stripe Connect, Slack, and Google have run self-service OAuth client registration for years. What's notable is that an infrastructure provider this central was, until now, still routing the long tail of integrations through static tokens. This is overdue parity, and that's a compliment.

The agentic forcing function

Cloudflare is candid that demand from agentic tools is what pushed this over the line, and the timing lines up with a parallel move on the other side of the house. In April, Cloudflare Access added managed OAuth in open beta so that AI agents speaking OAuth 2.0 can authenticate to internal applications on a user's behalf. That implementation leans on open standards, including RFC 9728 for protected-resource metadata discovery: an unauthenticated agent hits a resource, gets a www-authenticate header pointing at the authorization metadata, and runs a normal OAuth flow to get a token. No bespoke per-integration wiring, no service accounts with standing privilege. They demoed it by adapting Opencode's web fetch tool to the flow.

Worth keeping the two features straight, because the naming invites confusion. Access managed OAuth makes your internal apps agent-ready with Cloudflare acting as the authorization server in front of them. Self-managed OAuth clients let you build apps that get delegated access to Cloudflare's own API. Different directions, same underlying thesis: the integration layer is moving from pasted secrets to standards-based, scoped, revocable delegation, and agents are the reason it's happening now rather than in three years. An agent that can spin up Workers, edit DNS, or purge cache on your behalf is precisely the thing you want gated by narrow scopes and one-click revocation, not a god-mode token.

The upgrade most users never noticed

The part developers should actually study is the migration. Cloudflare's OAuth has run on Ory Hydra, an open-source OAuth/OIDC engine, for years. Fine for a curated partner list, not fine for opening the floodgates, so they had to move off an aging deployment through the 1.x line and then to 2.x. They split it into two sequential upgrades deliberately, to isolate behavior and performance changes before stacking a major version bump on top.

Advertisement

AirDroid Personal Best mobile device management suite — only $3.99/mo →

Even the 1.x step was hostile. Hydra's schema migrations created indexes that took an exclusive lock on critical tables, which would have frozen live OAuth operations, and added or relocated columns in a way that collided with a quirk where the SDK issued SELECT * and then choked on deserialization. The fixes are the kind of thing every team running Postgres at scale eventually learns the hard way: rewrite the migrations to use CREATE INDEX CONCURRENTLY so index builds don't block writers, and ship a patched Hydra that selects explicit columns instead of SELECT * so schema drift doesn't break reads.

The 2.x jump was too large for an in-place upgrade, so they went blue-green, with a catch: the cutover would take hours, and the system had to keep working the whole time. The naive blue-green option (freeze writes, no new authorizations) had an unacceptable failure mode. With writes frozen, a user who needed to revoke a compromised app's access couldn't. Security feature, disabled exactly when you'd want it.

Two moves solved it:

• Cut the write volume instead of stopping it. They raised token expiry to several hours so apps that grabbed a token before the cutover kept working without hammering the database for refreshes. Fewer writes to lose in the switch.
• Never drop a revocation. Each revocation during the window was recorded into a Cloudflare Queue, then drained against the green database once it was live. Eating the platform's own dog food to make the security-critical path durable through a migration.

The honest trade-off is right there in the design: they accepted losing some writes in the cutover, and bought back the one class of write that mattered with a queue. That's the correct instinct. Not every write is equally important, and pretending otherwise is how migrations turn into multi-hour outages.

What this means if you build on Cloudflare

If you ship anything that integrates with customers' Cloudflare accounts (a SaaS dashboard, an internal developer platform, a deploy bot, an agent), this changes your onboarding. The old flow asked users to read your docs, generate an API token with the right permissions, and paste it. The new flow is: register an OAuth client, declare scopes, implement the redirect and token exchange, and let users approve. You stop storing long-lived account credentials and start handling short-lived access tokens plus refresh logic.

Where it's clearly worth the switch:

• Anything multi-tenant or public-facing. Removing standing customer secrets from your database is a meaningful reduction in breach blast radius and audit pain. If you go public, budget for domain verification up front.
• Agent and automation tooling. Scoped, user-revocable grants are the right primitive for software acting on someone's behalf. This is where the model earns its keep.

Where API tokens are still fine:

• First-party automation you own end to end. CI deploying your own Workers, a cron job in your own account. No delegation, no third party, no reason to add an OAuth dance.

The costs are the standard OAuth costs, and they're real. You now own redirect handling, token refresh, secure client-secret storage, and the failure cases when a refresh token expires or a user revokes mid-session. That's strictly more code than reading a token from an env var. The payoff is that you're no longer the company holding a pile of other people's permanent keys.

This isn't a paradigm shift so much as Cloudflare closing a gap that should have closed sooner, and doing the unglamorous database work to close it without taking auth down for the customers who already depend on it. For the rest of us, the takeaway is narrower and more useful: when a platform finally offers you scoped, revocable OAuth for delegated access, the static token in your integration is now tech debt. Treat it that way.