从全或无到基于任务的 OAuth 同意
自六月份以来，开发者们已经创建了成千上万的 [Cloudflare 第三方 OAuth 应用](https://blog.cloudflare.com/oauth-for-all/)，并且进行了超过一百万次授权。
OAuth 使得授权访问成为可能。它允许应用在用户的授权下进行操作，而不需要用户处理长期凭证或直接交出密码。对于可以用一小部分范围描述其访问需求的应用，这种模型非常有效。
开发者们将 OAuth 用于 SaaS 集成、内部工具、CLI 和代理。我们的权限模型随着时间的推移变得越来越细化，以支持这些不同工作流程的更好范围划分。这在安全性上是一个好事，但这使得单纯的全或无同意屏幕很难得到合理的解释。
Cloudflare OAuth 已经允许客户端请求其配置范围的子集。但一旦客户端提出了请求，用户在同意屏幕上便无法进一步缩小。对用户而言，这个同意屏幕的体验仍然是全或无的。如果一个应用请求的访问权限超出了用户希望授予的范围，用户的唯一选择就是批准全部请求，或者直接拒绝。
MCP 服务器就是一个很好的例子。一个 MCP 服务器可能请求广泛的权限，因为理论上代理可以使用所有这些权限。但是大多数用户并不希望代理拥有这么多的访问权限。在此功能推出之前，处理这个问题的唯一方法是应用开发者在将用户引导到我们的同意流程之前，构建一个自定义的范围选择屏幕。
今天，我们推出了 OAuth 范围自定义功能。客户端所有者可以在配置 OAuth 客户端时将特定范围标记为可选，从而使用户在授权时能够授予应用请求的访问权限的更小子集。
OAuth 规范已经允许授权服务器授予比请求的更小范围。我们在这个灵活性基础上构建，使其可以为每个现有应用平稳运行。
## 更多控制，而不会让用户感到不知所措
我们推出范围选择的目标是让注重安全的用户在不将同意屏幕变成冗长范围清单的情况下，更灵活地做出适合他们使用情况的选择。
通过范围自定义：
- 开发者可以将特定范围在 OAuth 客户端上标记为必需或可选
- 在授权时，用户可以从请求的范围中取消选择可选范围
- 必需和可选范围将根据请求的范围进行评估
- 如果没有请求可选范围，同意体验将保持不变
- 默认情况下，同意屏幕仍然授予完整请求的范围集。
## 作用于授权请求的范围
一个重要的细节是，必需和可选范围仅针对特定授权流程中请求的范围进行评估，而不是针对客户端上配置的每个范围。这一点很重要，因为 OAuth 客户端并不总是请求其完整的配置范围。
例如，一个客户端可能配置了 [user-details.read](http://user-details.read)，workers-scripts.write，workers-kv-storage.write 和 [zone.read](http://zone.read)，同时将 workers-kv-storage.write 和 [zone.read](http://zone.read) 标记为可选。如果该客户端开始授权流程，请求所有四个范围，同意屏幕将评估所有四个。在这种情况下，[user-details.read](http://user-details.read) 和 workers-scripts.write 保持必需，而用户可以选择是否授予 workers-kv-storage.write 和 [zone.read](http://zone.read)。
但如果客户端后来仅请求 workers-scripts.write 和 [zone.read](http://zone.read)，那么在该授权流程中仅考虑这两个范围。 [user-details.read](http://user-details.read) 和 workers-kv-storage.write 将不会显示或强制执行，因为它们没有被请求。
这将同意屏幕的重点保持在当前任务上，而不是应用程序可以请求的每一种能力。这也意味着现有的 OAuth 客户端默认保留其当前行为：如果客户端未选择可选范围，则同意流程保持不变。
## 配置 OAuth 客户端以使用可选范围
开发者可以在配置 OAuth 客户端时选择使用范围自定义。范围的配置方式与今天相同，客户现在可以额外指定哪些范围是可选的：
在上面的示例中，客户端可以请求所有四个范围，但用户在同意期间可能仅选择不包括 `workers-kv-storage.write` 和 `zone.read` 的权限。如果这些在授权请求中包含，则 `user-details:read` 和 `workers-scripts.write` 仍然是必需的。
如果客户端后来仅请求 `workers-scripts.write` 和 `zone.read`，那么在该授权流程中仅考虑这两个范围。 `user-details.read` 和 `workers-kv-storage.write` 将不会显示或强制执行，因为它们没有被请求。
## 建立以部分授权为考虑
当用户取消选择任何可选范围并完成授权流程时，生成的访问令牌将仅包含他们同意的范围。对于开发者而言，这意味着需要在交换授权码后检查授予的范围集，而不是假设全部请求的范围都已获得批准。
一个能优雅地处理较小授权的应用，例如一个在其接收的权限子集范围内操作的代理，是用户感到舒适授权的应用。仅请求必要权限并将其余标记为可选，向用户表明你的应用尊重他们的访问决定。
## 针对每个产品的范围
在接下来的几周内，我们将扩大我们的帐户和区域级角色覆盖面，几乎涵盖每个 Cloudflare 产品。这意味着更多的 API 令牌角色、帐户成员选项和 OAuth 范围，使客户可以获得以适当访问级别安全工作负载的工具。
## 使用可选范围构建
允许开发者和用户通过可选 OAuth 范围更好地限制访问，是朝着在 Cloudflare 上实现更灵活和更值得信赖的同意体验迈出的重要一步。通过可选范围，开发者可以构建更细致的授权流程，而用户在批准时也享有更多控制权。
要开始使用第三方 OAuth，请查看我们的 [文档](https://developers.cloudflare.com/fundamentals/oauth/) 或直接前往仪表板的 OAuth 应用页面，[创建你的第一个 OAuth 应用](https://dash.cloudflare.com/?to=/:account/oauth-clients)。
## 感谢我们的优秀实习生
这个功能是我们在 [1,111 名实习生](https://blog.cloudflare.com/cloudflare-1111-intern-program/) 的帮助下开发的众多功能之一。祝贺 Miller Vargas 和 José Enrique Rodriguez 在这个项目上的重要贡献。Miller 是德克萨斯大学奥斯汀分校的计算机科学和数学专业的毕业生；而 José 则是泛美大学的工程、数据智能和网络安全专业的毕业生。
---
原文链接：[点击查看](https://blog.cloudflare.com/task-based-oauth-consent/)
OAuth 使得授权访问成为可能。它允许应用在用户的授权下进行操作，而不需要用户处理长期凭证或直接交出密码。对于可以用一小部分范围描述其访问需求的应用，这种模型非常有效。
开发者们将 OAuth 用于 SaaS 集成、内部工具、CLI 和代理。我们的权限模型随着时间的推移变得越来越细化，以支持这些不同工作流程的更好范围划分。这在安全性上是一个好事，但这使得单纯的全或无同意屏幕很难得到合理的解释。
Cloudflare OAuth 已经允许客户端请求其配置范围的子集。但一旦客户端提出了请求，用户在同意屏幕上便无法进一步缩小。对用户而言，这个同意屏幕的体验仍然是全或无的。如果一个应用请求的访问权限超出了用户希望授予的范围，用户的唯一选择就是批准全部请求，或者直接拒绝。
MCP 服务器就是一个很好的例子。一个 MCP 服务器可能请求广泛的权限，因为理论上代理可以使用所有这些权限。但是大多数用户并不希望代理拥有这么多的访问权限。在此功能推出之前，处理这个问题的唯一方法是应用开发者在将用户引导到我们的同意流程之前，构建一个自定义的范围选择屏幕。
今天，我们推出了 OAuth 范围自定义功能。客户端所有者可以在配置 OAuth 客户端时将特定范围标记为可选，从而使用户在授权时能够授予应用请求的访问权限的更小子集。
OAuth 规范已经允许授权服务器授予比请求的更小范围。我们在这个灵活性基础上构建，使其可以为每个现有应用平稳运行。
## 更多控制，而不会让用户感到不知所措
我们推出范围选择的目标是让注重安全的用户在不将同意屏幕变成冗长范围清单的情况下，更灵活地做出适合他们使用情况的选择。
通过范围自定义：
- 开发者可以将特定范围在 OAuth 客户端上标记为必需或可选
- 在授权时，用户可以从请求的范围中取消选择可选范围
- 必需和可选范围将根据请求的范围进行评估
- 如果没有请求可选范围，同意体验将保持不变
- 默认情况下，同意屏幕仍然授予完整请求的范围集。
## 作用于授权请求的范围
一个重要的细节是，必需和可选范围仅针对特定授权流程中请求的范围进行评估，而不是针对客户端上配置的每个范围。这一点很重要，因为 OAuth 客户端并不总是请求其完整的配置范围。
例如，一个客户端可能配置了 [user-details.read](http://user-details.read)，workers-scripts.write，workers-kv-storage.write 和 [zone.read](http://zone.read)，同时将 workers-kv-storage.write 和 [zone.read](http://zone.read) 标记为可选。如果该客户端开始授权流程，请求所有四个范围，同意屏幕将评估所有四个。在这种情况下，[user-details.read](http://user-details.read) 和 workers-scripts.write 保持必需，而用户可以选择是否授予 workers-kv-storage.write 和 [zone.read](http://zone.read)。
但如果客户端后来仅请求 workers-scripts.write 和 [zone.read](http://zone.read)，那么在该授权流程中仅考虑这两个范围。 [user-details.read](http://user-details.read) 和 workers-kv-storage.write 将不会显示或强制执行，因为它们没有被请求。
这将同意屏幕的重点保持在当前任务上，而不是应用程序可以请求的每一种能力。这也意味着现有的 OAuth 客户端默认保留其当前行为：如果客户端未选择可选范围，则同意流程保持不变。
## 配置 OAuth 客户端以使用可选范围
开发者可以在配置 OAuth 客户端时选择使用范围自定义。范围的配置方式与今天相同，客户现在可以额外指定哪些范围是可选的：
在上面的示例中，客户端可以请求所有四个范围，但用户在同意期间可能仅选择不包括 `workers-kv-storage.write` 和 `zone.read` 的权限。如果这些在授权请求中包含，则 `user-details:read` 和 `workers-scripts.write` 仍然是必需的。
如果客户端后来仅请求 `workers-scripts.write` 和 `zone.read`，那么在该授权流程中仅考虑这两个范围。 `user-details.read` 和 `workers-kv-storage.write` 将不会显示或强制执行，因为它们没有被请求。
## 建立以部分授权为考虑
当用户取消选择任何可选范围并完成授权流程时，生成的访问令牌将仅包含他们同意的范围。对于开发者而言，这意味着需要在交换授权码后检查授予的范围集，而不是假设全部请求的范围都已获得批准。
一个能优雅地处理较小授权的应用，例如一个在其接收的权限子集范围内操作的代理，是用户感到舒适授权的应用。仅请求必要权限并将其余标记为可选，向用户表明你的应用尊重他们的访问决定。
## 针对每个产品的范围
在接下来的几周内，我们将扩大我们的帐户和区域级角色覆盖面，几乎涵盖每个 Cloudflare 产品。这意味着更多的 API 令牌角色、帐户成员选项和 OAuth 范围，使客户可以获得以适当访问级别安全工作负载的工具。
## 使用可选范围构建
允许开发者和用户通过可选 OAuth 范围更好地限制访问，是朝着在 Cloudflare 上实现更灵活和更值得信赖的同意体验迈出的重要一步。通过可选范围，开发者可以构建更细致的授权流程，而用户在批准时也享有更多控制权。
要开始使用第三方 OAuth，请查看我们的 [文档](https://developers.cloudflare.com/fundamentals/oauth/) 或直接前往仪表板的 OAuth 应用页面，[创建你的第一个 OAuth 应用](https://dash.cloudflare.com/?to=/:account/oauth-clients)。
## 感谢我们的优秀实习生
这个功能是我们在 [1,111 名实习生](https://blog.cloudflare.com/cloudflare-1111-intern-program/) 的帮助下开发的众多功能之一。祝贺 Miller Vargas 和 José Enrique Rodriguez 在这个项目上的重要贡献。Miller 是德克萨斯大学奥斯汀分校的计算机科学和数学专业的毕业生；而 José 则是泛美大学的工程、数据智能和网络安全专业的毕业生。
---
原文链接：[点击查看](https://blog.cloudflare.com/task-based-oauth-consent/)
评论
暂无评论。