Cloudflare opens self-managed OAuth to every developer

Anyone who builds a program that has to “talk” to an online service - say an app that manages sites, DNS or firewalls on a customer’s behalf - sooner or later hits a practical question: how do I let my software access someone else’s account, securely, without asking for their password? On June 3, 2026, Cloudflare - one of the world’s largest network and CDN operators - made a tool built for exactly this available to all its customers: self-managed OAuth, meaning the ability to create your own OAuth applications yourself. Until shortly before, it was a feature reserved for a small group of hand-approved partners; now anyone with an account can use it.

The starting point: API tokens

To understand the news, it helps to look at how you access the Cloudflare API today. An API is the interface a program uses to command a service without going through the website: creating a DNS record, adding a rule, reading some statistics. To authorize these actions you normally use an API token: a long secret string that works like a key. Whoever holds it can perform whatever that token allows.

Tokens do the job, but they carry some awkward limits when you’re building integrations for other people. They’re often long-lived and broadly scoped, because it’s convenient to mint one that “does everything”. They have to be handed to the program that will use them, which means sharing a secret: if it ends up in the wrong place, maybe through a compromised software dependency as happened recently with the quarantined npm packages, whoever holds it can act on the account until the token is deleted. And if a customer wants to revoke access for a single application, working out which token belongs to whom isn’t always straightforward. In short: handy for personal use, a poor fit for delegating limited access to third-party software.

What OAuth is, and what changes

OAuth is an authorization standard used across the web. It’s the same mechanism behind the “Sign in with Google” or “Connect your account” buttons: instead of handing over a password or a key, the user is sent to the service’s own site, confirms which permissions to grant the application, and comes back with a limited authorization. The application never sees the user’s credentials; it only receives permission to do the little it was granted.

Compared with a token handed over by hand, the OAuth model brings three concrete benefits. The first is explicit consent: the user decides, in front of a clear screen, what to authorize. The second is least privilege: the application asks only for the permissions it needs, not the keys to everything. The third is clean revocation: the user can remove access for that single application from their dashboard, without touching anything else.

What Cloudflare announced

The change is that any Cloudflare customer can now create and manage their own OAuth applications on their own, without being a selected partner. You do it from the dashboard, under Manage account > OAuth clients, or via the API if you prefer to automate. From there you define the application, choose the permissions, and get the credentials you need to start the authorization flow.

It’s a feature available to everyone (general availability), not a beta. Cloudflare describes it as a more secure, more user-friendly and more manageable alternative to API tokens, especially for scenarios where an application acts on a user’s behalf.

Fine-grained permissions

At the heart of it are scopes, the permissions an application can request. On Cloudflare, scope names correspond to the same permissions you’d find when creating an API token, so you can pick exactly what to grant access to - read-only DNS for a zone, say, or management of one specific feature - instead of handing over everything at once. You can browse the available scopes from the dashboard while creating the client, or fetch them via the API.

The practical effect is that a well-built integration asks only for what it needs. If that application is ever compromised, the damage stays confined to the permissions it was granted, not the whole account.

Cloudflare distinguishes two kinds of application. A private client can be authorized only by members of the account that created it: it’s meant for an organization’s internal tools. A public client can instead be authorized by any Cloudflare user: that’s the case for a SaaS product offering a “connect your Cloudflare account” button to its customers.

Public clients come with an extra step to protect users: domain verification. Whoever publishes the application has to prove they control their domain by adding a DNS TXT record with a code Cloudflare provides. Once verified, the application earns a badge on the consent screen, so anyone about to authorize it knows who they’re dealing with. That same screen was reworked to make it clear which application is requesting access and what permissions it receives.

Client secrets and PKCE

A technical detail worth knowing for anyone building these integrations: Cloudflare supports the OAuth 2.0 flow called authorization code, in line with the latest OAuth security best practices, and rules out other types that are a poorer fit for secure delegated access. In this flow, an application running on its own server can hold a client secret, an application password kept out of sight. Applications that instead run entirely on the user’s device - a mobile app, a desktop program, a web page - can’t hide a secret and must use a mechanism called PKCE, which protects the exchange without needing to guard a key. It’s an important distinction: the explicit advice is never to embed the client secret in code that ends up on the user’s device.

What it’s for

Three scenarios open up in particular. The first is SaaS products that manage Cloudflare infrastructure on customers’ behalf: they can now offer a real “connect your account” flow, with targeted permissions, instead of asking the user to generate and paste a token. The second is internal developer platforms: a company can build tools that act on its own Cloudflare resources with per-user authorization. The third, more recent, involves AI agents and MCP servers - programs that act on a person’s behalf: they too finally have a delegated-access model built for the purpose, rather than having to be handed a broadly scoped token.

Why it matters

The value isn’t in a single flashy feature, but in removing friction from a recurring problem. People building integrations can ask only for the permissions they need, users can see clearly what they’re authorizing, and they can revoke access for a specific application with one click. It’s the model most of the web is already used to, now extended to the Cloudflare API and opened to anyone, not just partners.

It should be said plainly that this doesn’t retire API tokens: for personal use or quick scripts they stay simpler and more direct. Self-managed OAuth shines when a third party is involved and you need to delegate limited access in a controlled way. Under the hood, to make the service available to everyone, Cloudflare upgraded the OAuth engine it relies on (the open source project Ory Hydra) through a zero-downtime migration: work invisible to users, but it explains why the feature only arrives now. For anyone building integrations with Cloudflare, it’s a missing piece that’s finally in place and worth trying on a real project.

# Cloudflare opens self-managed OAuth to every developer