Cloudflare Lets Users Selectively Decline Permissions in OAuth Consent Screens

Cloudflare has introduced a way for developers to designate specific OAuth permissions as optional, allowing users to pick and choose which access rights to grant during the consent process rather than accepting or rejecting an entire permission bundle.

The Problem With Agent Permissions#

AI agents and MCP servers often need to request broad sets of permissions because they may theoretically use all of them—but most users won't want to grant that level of access. An inventory comparison agent shouldn't need pricing change permissions; an order status checker doesn't require refund authority; a supplier research tool doesn't need payment access.

This creates a dilemma for developers: request too few permissions and advanced features break; request everything and watch users abandon the consent screen entirely. As software engineer Umesh Malik describes it, developers face a choice between "request minimal permissions and break advanced use cases, or request everything and watch users bounce from the consent screen."

Previously, Cloudflare's OAuth implementation offered binary approval: either the user allowed all requested scopes or denied them. Some developers worked around this by building custom permission-selection screens before the official consent flow.

How It Works#

Client owners can now tag scopes as optional using an optional_scopes array when configuring their OAuth application:

"scopes": [
  "user-details.read",
  "workers-scripts.write",
  "workers-kv-storage.write",
  "zone.read"
],
"optional_scopes": [
  "workers-kv-storage.write",
  "zone.read"
]

The key behavior: permissions are evaluated based on what a specific authorization request asks for, not the entire set configured on the client. A client set up with four scopes that requests only two will show the user just those two. Applications that don't opt into the feature continue working as before, granting the full requested scope set by default.

Developer Responsibilities#

What complicates adoption is that developers cannot force users to grant required permissions—the user has final say. Applications must now inspect the parameter in the token response after authorization, rather than assuming success means full access was granted. Code expecting all permissions will encounter authorization failures on calls it counted on.