OAuth 让应用可以代表用户行事，但当应用请求的权限超出用户意愿时，同意屏幕往往只剩“全部批准”或“直接拒绝”两个选项。Cloudflare 近期推出 OAuth 范围自定义功能，允许开发者将部分范围标记为可选，让用户在授权时按需缩小权限集合。本文基于 Cloudflare Blog 官方技术解读，梳理这一机制的实现逻辑、配置方式与对开发者的影响。

　　一、问题：精细权限模型与粗放同意体验的错位

　　OAuth 的核心价值在于委托访问——应用无需用户交出密码或长期凭证，即可代表用户执行操作。当应用能够用一小部分范围（scope）描述其访问需求时，这种模式运转良好。

　　开发者将 OAuth 用于 SaaS 集成、内部工具、命令行界面和智能体（agent）等多种场景。随着时间推移，Cloudflare 的权限模型变得更加精细，以更好地支持这些不同工作流的范围界定。这对安全有利，但也让纯粹“全有或全无”的同意屏幕越来越难以自圆其说。

　　依据素材，Cloudflare OAuth 此前已经允许客户端请求其配置范围的一个子集。但一旦客户端提出该请求，用户无法在同意屏幕上进一步缩小范围。对用户而言，体验仍然是全有或全无的：如果应用请求的访问权限超出用户愿意授予的范围，唯一选择是批准完整请求或直接拒绝。

　　MCP 服务器是一个典型例子。MCP 服务器可能请求广泛的权限集，因为理论上智能体可能用到所有这些权限。但大多数用户并不希望智能体拥有那么多访问权限。在此功能之前，处理该问题的唯一方式是让应用开发者在将用户引导至同意流程之前，自行构建自定义范围选择屏幕。

　　二、方案：把部分范围标记为“可选”

　　Cloudflare 推出的 OAuth 范围自定义功能，允许客户端所有者在配置 OAuth 客户端时将特定范围标记为可选，从而使用户在授权时能够授予应用程序请求访问权限的一个更窄子集。

　　值得注意的是，OAuth 规范本身已经允许授权服务器授予比请求更窄的范围集。Cloudflare 基于这种灵活性进行构建，使该功能能够干净地适用于每个现有应用。

　　其设计目标是：为注重安全的用户提供更多灵活性，以便他们为自己的用例做出正确选择，同时不把同意屏幕变成一长串范围清单。

　　通过范围自定义：

　　开发者可以将 OAuth 客户端上的特定范围标记为必需或可选；

　　在授权时，用户可以从请求集中取消选择可选范围；

　　必需和可选范围将根据该授权流程请求的范围进行评估；

　　如果未请求可选范围，同意体验保持不变；

　　默认情况下，同意屏幕仍授予完整的请求范围集。

　　三、关键细节：范围界定针对“本次授权请求”

　　一个容易被忽略但非常重要的细节是：必需和可选范围仅针对特定授权流程中请求的范围进行评估，而非客户端上配置的所有范围。这一点之所以重要，是因为 OAuth 客户端并不总是请求其完整配置的范围集。

　　素材给出了一个具体示例。假设某客户端配置了 `user-details.read`、`workers-scripts.write`、`workers-kv-storage.write` 和 `zone.read`，并将 `workers-kv-storage.write` 和 `zone.read` 标记为可选：

　　如果该客户端启动一个请求全部四个范围的授权流程，同意屏幕将评估所有四个范围。此时 `user-details.read` 和 `workers-scripts.write` 保持必需，而用户可以选择是否授予 `workers-kv-storage.write` 和 `zone.read`。

　　如果客户端稍后仅请求 `workers-scripts.write` 和 `zone.read`，那么该授权流程仅考虑这两个范围。`user-details.read` 和 `workers-kv-storage.write` 将不会显示或强制执行，因为它们未被请求。

　　这种设计让同意屏幕专注于当前任务，而非应用程序可能请求的所有能力。同时也意味着现有 OAuth 客户端默认保持其当前行为：如果客户端未选择可选范围，同意流程保持不变。

　　四、如何配置：一个 API 调用示例

　　开发者在配置 OAuth 客户端时可以选择范围自定义。范围继续按当前方式配置，客户端现在还可以指定其中哪些范围是可选的。素材给出的请求示例如下：

　　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"

　　]

　　}'

　　在上述示例中，客户端可以请求所有四个范围，但用户在同意期间只能选择退出 `workers-kv-storage.write` 和 `zone.read` 范围。如果授权请求中包含 `user-details:read` 和 `workers-scripts.write`，则它们保持必需。

　　五、对开发者的影响：必须处理“部分授权”

　　当用户取消选择任何可选范围并完成授权流程时，生成的访问令牌将仅包含他们同意的范围。对开发者而言，这意味着需要在交换授权代码后检查授予的范围集合，而不是假设完整的请求范围集已被批准。

　　素材明确指出，一个能够优雅处理较窄授权的应用——例如在其收到的任何权限子集内运行的智能体——会让用户感到放心授权。仅请求所需权限并将其余标记为可选，是向用户表明应用尊重其访问决定的好信号。

　　换句话说，可选范围不仅是同意屏幕上的一个交互改进，也对应用侧的权限处理逻辑提出了新要求：应用需要具备“在任意权限子集内正常工作”的能力。

　　六、趋势判断：权限表面持续扩展

　　素材提到，在接下来的几周内，Cloudflare 将扩展账户和区域级别的角色表面，以覆盖几乎所有的 Cloudflare 产品。这意味着更多的 API 令牌角色、账户成员选项和 OAuth 范围，为客户提供以适当访问级别保护工作负载的工具。

　　结合本次 OAuth 可选范围的推出，可以看出一条清晰的路径：权限模型越精细，同意体验就越需要相应的“减法”机制。可选范围正是把“缩小权限”的能力从应用开发者手中，部分交还给最终用户。

　　七、结论

　　Cloudflare 的 OAuth 范围自定义功能，把同意屏幕从“全有或全无”推进到基于任务的授权模式。其核心机制可以概括为三点：

　　开发者在配置 OAuth 客户端时，将部分范围标记为可选；

　　用户在授权时，可针对本次授权流程请求的范围取消选择可选范围；

　　应用需要在授权后检查实际授予的范围集合，并能在较窄授权下正常工作。

　　依据现有素材判断，这一功能并未改变 OAuth 规范本身，而是利用了规范中“授权服务器可授予更窄范围集”的既有灵活性。对于正在构建 SaaS 集成、内部工具、CLI 或智能体的开发者而言，将非必要权限标记为可选，正在成为一种兼顾安全与用户体验的默认实践。

　　配图建议：可插入 OAuth 同意屏幕对比示意图，左侧为“全有或全无”授权界面，右侧为带可选范围勾选框的授权界面，用于直观呈现本次功能变化。

　　生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。