Cloudflare OAuth Gets Task-Based Consent: Users Can Now Opt Out of Optional Scopes

Cloudflare is rolling out OAuth scope customization, a feature that lets users deselect optional scopes on the consent screen before authorizing a third-party app. Until now, the consent screen was all-or-nothing: you either approved the full requested scope set or denied the whole thing. That's a poor fit for modern workloads like MCP servers and AI agents, which often request broad permissions because they might need them — not because they always do.

The change is built on a flexibility already present in the OAuth spec: authorization servers may grant a narrower set of scopes than what was requested. Cloudflare is simply exposing that capability to developers and users.

How it works

When configuring an OAuth client, developers can mark specific scopes as optional_scopes. At authorization time, the user sees the requested scopes and can uncheck the optional ones. Required scopes stay locked. If no optional scopes are requested, the consent screen behaves exactly as before — no regression for existing apps.

An important nuance: optional and required scopes are evaluated against the scopes requested in a given authorization flow, not the client's full configured scope set. If a client requests only a subset, only that subset is shown and enforced. This keeps the consent screen focused on the task at hand rather than every capability the app could theoretically use.

What developers need to do

If you're building an OAuth app on Cloudflare, you need to handle partial grants. After exchanging the authorization code, check the actual granted scope set instead of assuming the full request was approved. Apps that gracefully operate within a narrower permission set will earn more user trust — and more authorizations.

Here's an example of configuring a client with optional scopes via the API:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/oauth_clients" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "client_name": "ACME Corp",
    "redirect_uris": ["https://acme.org/oauth/callback"],
    "grant_types": ["authorization_code"],
    "response_types": ["code"],
    "token_endpoint_auth_method": "client_secret_basic",
    "scopes": ["user-details.read", "workers-scripts.write", "workers-kv-storage.write", "zone.read"],
    "optional_scopes": ["workers-kv-storage.write", "zone.read"]
  }'

In this example, user-details.read and workers-scripts.write remain required, while the user can opt out of the other two.

Why this matters for agents

This is a direct response to the rise of AI agents and MCP servers. An MCP server might request a broad set of permissions because an agent could use them all — but most users don't want to hand over that much access. Previously, the only workaround was for the app developer to build a custom scope-selection screen before redirecting to Cloudflare's consent flow. Now it's built in.

Cloudflare also notes it's expanding its account and zone-level role surface to cover nearly every product, meaning more granular OAuth scopes and API token roles are on the way.

The feature is live now. Existing clients keep their current behavior by default; opting in is a configuration change, not a migration.