Cloudflare OAuth 支持可选 scope：用户授权时能勾掉多余权限，智能体应用不再全有或全无

一句话结论

Cloudflare OAuth 引入 scope 定制：OAuth 客户端拥有者可在配置时把特定 scope 标记为可选，用户在授权时可以取消勾选这些可选权限，拿到一个权限更窄的访问令牌。对 AI 智能体类应用尤其关键——智能体理论上能用到的权限和用户实际愿意给的权限之间差距巨大，全有或全无的授权页把这种差距变成了信任鸿沟。

OAuth 的授权粒度问题

6 月以来，开发者在 Cloudflare 上创建了数千个第三方 OAuth 应用，累计产生超过一百万次授权。

OAuth 让委托访问成为可能：应用代表用户行动，而不要求用户处理长期凭据或交出密码。这个模型在应用能用一小撮 scope 描述访问需求时运转良好。

开发者用 OAuth 做 SaaS 集成、内部工具、命令行工具和智能体。Cloudflare 的权限模型随时间变得越来越细，以支撑这些不同工作流的更好隔离。这对安全是好事，但也让纯”全有或全无”的授权页变得难以自圆其说。

Cloudflare OAuth 早已允许客户端请求其已配置 scope 的子集。但客户端发起请求后，用户无法在授权页上进一步收窄。对授权页上的用户来说，体验仍是全有或全无：应用请求的权限超出用户愿意给的范围时，用户只有两个选项——批准全部请求，或干脆拒绝。

MCP 服务器是个典型例子。一个 MCP 服务器可能申请一大堆权限，因为理论上智能体能用到全部。但多数用户不想给智能体这么大权限。这个功能出现前，唯一办法是应用开发者自己建一个自定义 scope 选择页，在把用户送去授权流程前先筛一遍。

今天 Cloudflare 发布 OAuth scope 定制。客户端拥有者在配置 OAuth 客户端时可把特定 scope 标记为可选，让用户在授权时能授权应用所请求访问范围中更窄的子集。

OAuth 规范本身已允许授权服务器授予比请求更窄的 scope 集。Cloudflare 在此灵活性之上构建，让每个现有应用都能干净地用上。

更多控制，但不淹没用户

引入 scope 选择的目的是给安全敏感用户更多灵活性，按自己的用例做对的选择，同时不把授权页变成长长的 scope 清单。

scope 定制的工作方式：

• 开发者可在 OAuth 客户端上把特定 scope 标记为必选或可选。
• 授权时，用户可从请求集中取消选择可选 scope。
• 必选和可选 scope 只针对该授权流程中实际请求的 scope 进行评估。
• 没有请求可选 scope 时，授权体验保持不变。
• 默认情况下，授权页仍授予完整请求的 scope 集。

按”本次授权请求”评估

一个重要细节：必选和可选 scope 只针对特定授权流程中请求的 scope 评估，而不是客户端上配置的全部 scope。这很重要，因为 OAuth 客户端不总是请求其完整配置的 scope 集。

例如，一个客户端可能配置了 user-details.read、workers-scripts.write、workers-kv-storage.write 和 zone.read，并把 workers-kv-storage.write 和 zone.read 标为可选。如果该客户端发起请求全部四个 scope 的授权流程，授权页会评估全部四个：user-details.read 和 workers-scripts.write 保持必选，用户可自行决定是否授予 workers-kv-storage.write 和 zone.read。

但如果客户端之后只请求 workers-scripts.write 和 zone.read，那次授权流程只考虑这两个 scope。user-details.read 和 workers-kv-storage.write 不会展示或强制，因为它们没被请求。

这让授权页聚焦当前任务，而不是应用可能请求的所有能力。同时也意味着现有 OAuth 客户端默认保持当前行为：客户端不启用可选 scope，授权流程就不变。

配置 OAuth 客户端使用可选 scope

开发者可在配置 OAuth 客户端时启用 scope 定制。scope 的配置方式与今天相同，客户端现在可以额外指定哪些 scope 是可选的：

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"
    ]
  }'

上面的例子里，客户端可以请求全部四个 scope，但用户在授权时只能取消 workers-kv-storage.write 和 zone.read。user-details.read 和 workers-scripts.write 只要包含在授权请求中就保持必选。

客户端之后只请求 workers-scripts.write 和 zone.read 时，那次授权流程只考虑这两个 scope。user-details.read 和 workers-kv-storage.write 不会展示或强制，因为未被请求。

面向部分授权的开发实践

用户取消任何可选 scope 并完成授权流程后，生成的访问令牌只包含用户同意的 scope。对开发者来说，这意味着你需要在交换授权码后检查实际授予的 scope 集，而不是假设请求的完整 scope 集都被批准。

能优雅处理更窄授权的应用——比如一个在收到的任何权限子集内运作的智能体——是用户放心授权的那种应用。只请求需要的权限、把其余标为可选，是向用户表明你的应用尊重其访问决策的好信号。

每个产品都会有对应 scope

未来几周，Cloudflare 将扩展账户和区域级角色面，覆盖几乎每个 Cloudflare 产品。这意味着更多 API 令牌角色、账户成员选项和 OAuth scope，给客户以正确的访问级别保护工作负载的工具。

用可选 scope 构建

让开发者和用户通过可选 OAuth scope 更好地限制访问，是 Cloudflare 上更灵活、更可信授权体验的重要一步。有了可选 scope，开发者可以构建更细粒度的授权流，用户对批准什么拥有更多控制。

要开始使用第三方 OAuth，查看文档，或直接到控制台的 OAuth 应用页创建你的第一个 OAuth 应用。

实操要点

部署智能体应用前先做权限拆分：把核心任务必须的 scope 标为必选，扩展能力对应的放进 optional_scopes；调用 oauth_clients API 创建客户端后，自己先走一遍授权流，检查取消勾选后功能是否优雅降级而不是报错，再换不同账号测试授权体验。

用户侧同样有可操作的判断：授权页看到可选权限时，按当前任务选择真正需要的项，其余取消勾选——智能体拿到的是窄令牌，即使后续被滥用，影响面也被限制在你同意的范围之内。

原文信息

• 作者：Miller Vargas、Adam Bouhmad、José Enrique Rodríguez（Cloudflare）
• 发布时间：2026-08-20 原文地址：