Summary: Cloudflare introduced OAuth scope customization on August 20, 2026, allowing users to uncheck optional scopes during authorization instead of accepting every requested permission. Developers must mark scopes required or optional and inspect the granted scope set after token exchange. The change is aimed at least-privilege consent for SaaS integrations, AI agents, and MCP servers.
Consent screens in OAuth have always worked on take-it-or-leave-it terms: a user either approves every permission an app asks for, or turns down the whole integration. That is the arrangement Cloudflare set out to loosen with a feature it calls OAuth scope customization, unveiled on August 20, 2026. The idea behind it is straightforward — while authorizing, a user can uncheck individual optional scopes, dropping the riskier ones there and then rather than giving up the connection altogether.
The people who feel this most sharply are those who build AI agents, or MCP (Model Context Protocol) servers. An integration of that kind often asks for a wide spread of permissions on the grounds that the agent might, in theory, use all of them — even though the typical user needs only a small slice. Cloudflare’s update lets users consent to something narrower, and leaves developers to cope with that outcome.
The Problem: Consent That Is All or Nothing
Requesting a subset was never the obstacle. The Cloudflare OAuth implementation has always let clients ask for only some of the scopes they had configured. The obstacle came afterward: once the client had settled on which scopes to request, the user had no lever to trim that list at the consent screen. Take the whole request or reject it outright — those were the only two outcomes available.
The friction this produced fell hardest on apps that genuinely need broad permissions for certain features while getting by on far less day to day. Anyone uneasy about granting write access on their zone settings — to take one example — found no middle option. The keys changed hands, or the user walked away.
What the new design does is draw on a flexibility the OAuth protocol has always allowed — an authorization server may issue a token whose scope set is narrower than the one requested. Cloudflare layers on top of that the ability for client owners to designate which scopes count as required and which as optional when they configure an OAuth client. Users can uncheck the optional ones as they authorize. When a given flow requests no optional scopes at all, the consent screen is indistinguishable from the old one. Unless the user acts, the whole requested scope set is what gets granted.
How It Works: Everything Hinges on the Request at Hand
One detail is worth holding onto: the required/optional distinction is measured against the scopes one authorization flow actually asks for — not the entire set the client has on file. Cloudflare’s illustration runs like this. Of the four scopes a client has configured, two are marked optional. A flow that requests all four lets the user uncheck those two. A different flow that requests only two of the scopes never surfaces the remaining pair, and nothing enforces them either.
The result is a consent screen that speaks to the job in front of the user rather than to every capability the app could conceivably reach for. Clients that never adopt optional scopes, meanwhile, will notice no difference at all.
What This Means for Developers
Once a user unchecks even one optional scope, the access token that comes back carries only the scopes that were approved. Inspecting the scope set actually granted, once the authorization code has been exchanged, therefore becomes the developer’s job. Assuming the full request went through is a mistake.
An app that copes well with a narrower grant — an agent that stays inside the permission subset it was handed, for instance — leaves users more inclined to say yes. Asking for nothing beyond what you need, and marking the remainder optional, sends the same kind of trust signal.
The TypeScript snippet below shows one way to inspect the granted scopes once the token exchange is done:
// After exchanging the authorization code for tokens
const grantedScopes = tokenResponse.scope.split(' ');
const requiredScopes = ['read:zones', 'write:zones'];
// Check if all required scopes are present
const hasAllRequired = requiredScopes.every(s => grantedScopes.includes(s));
if (!hasAllRequired) {
// Handle the case where the user didn't grant all required scopes
console.warn('User did not grant all required scopes. Adjusting behavior.');
}Where It Matters Most: MCP Servers and AI Agents
No case is sharper than the MCP server. Such a server may request a broad permission set on the theory that the agent could use every feature, yet most users would rather not give an agent that much reach. The only option used to be for the app developer to build its own scope-picking screen and hand users off to Cloudflare’s consent flow. Marking some scopes optional changes that: the decision goes back to the user.
Take an MCP server that manages Cloudflare zones and requests read:zones, write:zones, and delete:zones. Make delete:zones optional, and a user who only needs to read and update settings can simply drop that permission — cutting the odds of an accidental deletion, or a malicious one.
Caveats and Trade-offs
The improvement is a welcome one, but a few caveats deserve a place alongside it:
- Nothing changes retroactively: A client that never adopts optional scopes keeps behaving exactly as it does today — and gains none of the new flexibility.
- The burden lands on developers: Reading the granted scopes and coping with a partial grant is now up to you. An app that assumes every requested scope came through may fail, or act in ways nobody expects.
- Scopes are judged per flow: The optional/required label reaches only the scopes one authorization flow actually requests. That forces developers to settle scope choices for every flow rather than once, at configuration time.
- Users need to be taught: What happens when a scope is unchecked may not be obvious. Confusion is kept out by clear copy and explanation in the UI.
What Comes Next, and What to Take Away
In the coming weeks, Cloudflare says, it will push role surfaces at the account and zone level out to nearly every Cloudflare product, which means the set of API token roles, OAuth scopes, and account membership options keeps growing. If a SaaS integration or an agent is what you’re building, the feature is available to try today, and checking which scopes were actually granted deserves to become a habit.
Four things worth doing as a product builder:
- Reserve “required” for what is genuinely necessary. The smaller that set, the more likely a user is to approve it.
- Verify granted scopes after every token exchange. Never assume the whole request went through.
- Build your app so that a subset of permissions is enough. The integration ends up sturdier and friendlier to users.
- Let optional scopes do the trust-building. Giving users a say over their permissions shows you respect both their security and their data.
Cloudflare’s move to task-based consent, away from the all-or-nothing model, puts it in step with the wider trend toward least-privilege access. For developers, the upshot is integrations flexible enough to run on whatever permissions a user is willing to hand over. It is a small change whose consequences reach far into how OAuth consent gets built once AI agents are part of the picture.