Cloudflare Introduces Optional Scopes for Task-Based OAuth Consent

Cloudflare Introduces Optional Scopes for Task-Based OAuth Consent Cloudflare has released OAuth scope customization, enabling client developers to mark specific scopes as optional so users can selectively grant permissions instead of facing an all-or-nothing consent screen. Since June, developers have created thousands of third-party OAuth apps on Cloudflare, totaling over one million authorizations. Previously, users had to approve all requested scopes or deny access entirely unless developers created custom pre-consent selection interfaces. Developers can now designate specific scopes as optional, allowing users to deselect them on the consent screen while required scopes remain mandatory. Access tokens reflect only the granted permissions, requiring developers to inspect the resulting scope set rather than assuming all requested scopes were approved. Addressing the All-or-Nothing Dilemma Cloudflare OAuth has seen rapid adoption, but its increasingly granular permission model created friction with all-or-nothing consent flows. Applications such as MCP servers and AI agents often request broad permission sets that users are hesitant to grant in full. Previously, users could only accept or reject an application's entire request unless developers engineered their own custom scope selection screens prior to initiating the authorization flow. Mechanics of Scope Customization The new feature allows OAuth client owners to designate certain scopes as optional during client configuration. During authorization, only scopes actively requested in that specific flow are evaluated. If an application requests both required and optional scopes, users can deselect optional ones on the consent screen. Existing clients retain their default behavior without changes unless developers explicitly opt into optional scopes. Developer Responsibilities and Future Expansions Because the generated access token contains only the permissions approved by the user, developers must verify the granted scope set following code exchange rather than assuming full authorization. Over the coming weeks, Cloudflare intends to expand its account- and zone-level roles, API token roles, account memberships, and OAuth scopes across nearly every Cloudflare product.

Cloudflare 推出 OAuth 可选权限功能，实现基于任务的细粒度授权 Cloudflare 宣布推出 OAuth 范围自定义（OAuth scope customization），开发者可将特定权限范围标记为可选，允许用户在授权时仅授予部分权限，告别以往“全有或全无”的同意流程。 自6月以来，开发者已在 Cloudflare 上创建数千个第三方 OAuth 应用，累计授权超过100万次。 以往用户面对应用请求的权限范围只能全盘接受或直接拒绝，新功能允许开发者将部分权限配置为可选。 授权屏幕仅评估当前流程中实际请求的权限范围，未请求的配置项不会展示或强制执行。 用户取消勾选可选权限后生成的访问令牌仅包含已同意范围，开发者需在换取令牌后检查实际获得的权限。 从“全有或全无”到灵活授权 以往 Cloudflare OAuth 客户端即便只请求部分配置权限，用户在授权页面也只能全部接受或拒绝。尤其在 MCP 服务器或 AI 代理等场景下，应用往往为了潜在功能请求大批权限，迫使开发者自行构建选择界面。新功能基于 OAuth 规范中允许授权服务器授予较窄权限集的机制，让开发者可将特定 scope 设为可选，提升注重安全的用户体验。 运作机制与开发者适配 必选与可选权限仅针对具体授权流程中实际请求的范围进行评估，未请求的 scope 不会在界面显示。未开启该功能的现有客户端保持原有行为不变。当用户取消勾选部分可选权限后，生成的 Access Token 仅包含被允许的范围，因此开发者在交换授权码后必须核对实际授予的权限，以便在受限权限下优雅运行。 后续权限体系扩展 未来几周，Cloudflare 将进一步扩大账户与区域级的角色范围，覆盖几乎所有 Cloudflare 产品，带来更多 API Token 角色、账户成员资格选项及 OAuth scopes。该功能由 Cloudflare 的实习生项目协作开发完成。

Since June, developers have created thousands of [third-party OAuth apps on Cloudflare](https://blog.cloudflare.com/oauth-for-all/), with more than a million authorizations since. OAuth makes delegated access possible. It lets applications act on a user’s behalf without asking them to handle long-lived credentials or hand over a password. That model works well when an application can describe its access needs with a small set of scopes. Developers use OAuth for SaaS integrations, internal tools, CLIs, and agents. Our permission model has become more granular over time to support better scoping of these different workflows. That is great for security, but it makes a purely all-or-nothing consent screen hard to justify. Cloudflare OAuth already allows clients to request a subset of their configured scopes. But once the client made that request, the user could not narrow it any further on the consent screen. For the user on the consent screen, the experience was still an all-or-nothing one. If an application requested more access than a user was comfortable granting, their only options were to approve the full request, or deny outright. MCP servers are a good example of this. An MCP server might request a broad set of permissions, because in theory an agent could use all of them. But most users would not want an agent to have that much access. Before this feature, the only way to handle this was for the app developer to build a custom scope selection screen before sending the user to our consent flow. Today, we’re introducing OAuth scope customization. Client owners can mark specific scopes as optional when configuring an OAuth client, giving users the ability to grant a narrower subset of an application’s requested access at authorization time. The OAuth spec already allows authorization servers to grant a narrower set of scopes than what was requested. We built on top of that flexibility to make this work cleanly for every existing app. Our goal with introducing scope selection is to give security conscious users more flexibility to make the right choices for their use case, without turning the consent screen into a long scope checklist. With scope customization: One important detail is that required and optional scopes are evaluated only against the scopes requested in a specific authorization flow, not every scope configured on the client. That matters because OAuth clients do not always request their full configured scope set. For example, a client might be configured with [`user-details.read`](http://user-details.read), `workers-scripts.write`, `workers-kv-storage.write`, and [`zone.read`](http://zone.read), while marking `workers-kv-storage.write` and [`zone.read`](http://zone.read) as optional. If that client starts an authorization flow requesting all four scopes, the consent screen will evaluate all four. In that case, [`user-details.read`](http://user-details.read) and `workers-scripts.write` remain required, while the user can choose whether to grant `workers-kv-storage.write` and [`zone.read`](http://zone.read). But if the client later requests only workers-scripts.write and [zone.read](http://zone.read), then only those two scopes are considered for that authorization flow. [user-details.read](http://user-details.read) and workers-kv-storage.write would not be shown or enforced, because they were not requested. This keeps the consent screen focused on the task at hand, rather than every capability the application could request. It also means existing OAuth clients keep their current behavior by default: if a client does not opt into optional scopes, the consent flow remains unchanged. Developers can opt into scope customization when configuring an OAuth client. Scopes continue to be configured as they are today, and clients can now additionally specify which of those scopes are optional: In the example above, the client can request all four scopes, but the user may only opt out of the `workers-kv-storage.write` and `zone.read` scopes during consent. `user-details:read` and `workers-scripts.write` remain required if they are included in the authorization request. If the client later requests only `workers-scripts.write` and `zone.read`, then only those two scopes are considered for that authorization flow. `user-details.read` and `workers-kv-storage.write` would not be shown or enforced because it was not requested. When a user deselects any optional scopes and completes the authorization flow, the generated access token will only contain the scopes they consented to. For developers, this means you need to check the granted scope set after exchanging the authorization code, rather than assuming the full requested set of scopes was approved. An app that handles a narrower grant gracefully, for example an agent that operates within whatever subset of permissions it receives, is one that users feel comfortable authorizing. Requesting only the permissions needed and marking the rest as optional is a good sign to users that your app respects their access decisions. Over the next few weeks, we will be expanding our account & zone-level role surface to cover nearly every Cloudflare product. That means more API token roles, account membership options, and OAuth scopes, giving customers the tools to secure workloads with the right level of access. Allowing developers and users to better restrict access through optional OAuth scopes is an important step toward a more flexible and trustworthy consent experience on Cloudflare. With optional scopes, developers can build more nuanced authorization flows, and users gain more control over what they approve. To get started with Third Party OAuth, take a look at our [documentation](https://developers.cloudflare.com/fundamentals/oauth/) or jump straight to the OAuth apps page in the dashboard and [create your first OAuth app](https://dash.cloudflare.com/?to=/:account/oauth-clients). This feature is one of the many that we built with the help of our [1,111 interns](https://blog.cloudflare.com/cloudflare-1111-intern-program/). Congratulations to Miller Vargas and José Enrique Rodriguez on your high impact contributions here. Miller is a senior at the University of Texas - Austin studying computer science and math; and José is a senior at Universidad Panamericana studying engineering, data intelligence, and cybersecurity.