Cloudflare 推出自管 OAuth，助力开发者构建集成
Cloudflare 提供服务，助力 20% 的互联网运行，但我们并不孤单。我们平台上的开发者还使用其他公司的多种工具和服务。Cloudflare 为我们的平台提供了丰富的 API，使开发者能够创建自动化、CI/CD 和集成，连接基础设施的各个部分。最近，我们宣布了 [自管 OAuth](https://developers.cloudflare.com/changelog/post/2026-06-03-public-oauth-clients/)，使客户能更轻松地创建和管理自己的 OAuth 客户端，以便委托访问 Cloudflare API。
Cloudflare 在 OAuth 方面并不陌生。如果你使用过 Wrangler，或从合作伙伴如 PlanetScale 等进行过集成，那么你已经使用过了。然而，在此之前，第三方 OAuth 仅通过少量手动集成提供，无法广泛接入给开发者。这意味着构建自己集成的开发者不得不依赖 API 令牌，而这些令牌难以管理，并且不适合许多委托应用流。
在过去的一年中，我们吸收了越来越多的早期合作伙伴，同时改进了 Cloudflare OAuth 背后的同意、撤回和安全模型。但随着我们开发者平台的增长和代理工具对委托访问的需求不断增加，显然，向所有客户开放 OAuth 是我们平台成功的关键。
自管 OAuth 的推出，让开发者能够提供标准的 OAuth 流程，客户可以直接授权特定的访问权限，这使得构建 SaaS 集成、内部开发平台和代理工具变得更加容易，同时用户在访问授权、撤回和控制应用能够执行的操作上也更加清晰。
### 安全扩展生态系统
我们的早期 OAuth 解决方案足以支持少量经过严格管理的合作伙伴，但我们意识到，我们的权限模型、同意体验以及对潜在滥用向量的防范措施还不够成熟。
今年早些时候，我们 [更新了同意体验](https://blog.cloudflare.com/improved-developer-security/#improving-the-oauth-consent-experience)，使得请求访问的应用和所获得的权限变得更加清晰。同时，我们在仪表板上增加了撤回功能，方便开发者轻松控制哪些应用可以访问他们的数据，并使应用所有权更加可见，以防止 OAuth 钓鱼攻击。
对所有客户开放自管 OAuth 还需要对我们底层的 OAuth 引擎进行重大升级。这一过程需要进行大量的计划，在尽量减少用户中断的情况下，同时确保数据稳定和安全。
### 规划 OAuth 引擎的升级
几年前，我们部署了 [Hydra](https://github.com/ory/hydra)，一个开源 OAuth 引擎，作为 Cloudflare OAuth 的底层驱动力。虽然在使用量有限时，这项部署表现良好，但随着开发者平台的发展和代理工作流变得更加普遍，我们意识到需要进行重大升级，以便解锁新功能并提升性能。
在规划升级时，我们决定进行两次较小的顺序升级，而不是一次大升级。首先，我们将升级至最新的 1.X 版本，评估任何行为或性能的变化，然后再进行 2.X 的升级。
在升级规划过程中，我们意识到，即使是 1.X 的升级仍将影响客户，因为 Hydra 数据库需要进行广泛的模式迁移，这会：
1. 以一种方式创建索引，这将对关键表格声称独占锁，从而阻止活动用户进行重要的 OAuth 操作。
2. 向关键表中添加列，并移动其他列到新表中。
而且，我们使用的 Hydra 版本存在一个小问题，使得 SDK 会执行 `SELECT *` 操作，导致与模式变更产生反序列化问题。
为了避免用户受影响，我们重写了 SQL 迁移，使用 `CREATE INDEX CONCURRENTLY` 等功能，并构建了一个自定义版本的 Hydra，选择明确的列，而不是 `SELECT *`。
在规划好最新的 1.X 升级后，我们现在需要为更大规模的 2.X 升级制定计划。我们识别了三种潜在选择，并权衡了每种方案的优缺点。由于大版本升级带来的大量模式更改，一次就地升级对我们而言不可行。我们决定采用蓝绿策略，但除了简单地切换开关开始使用新版本外，还需要做更多工作。升级和迁移过程将需要数个小时，我们需要在这段时间内确保系统继续正常运行。
第一个蓝绿选项将涉及禁用对数据库的写入，阻止任何新的授权发生。这意味着在切换到绿色版本时不会丢失授予，但也意味着在升级期间，如果用户需要出于任何原因撤回应用的访问，将无法进行。
为了解决这些问题，我们想出了保持对数据库的写入启用的方法，代价是可能会在切换到绿色版本时失去一部分写入。我们采取的操作是：延长令牌的过期时间到数小时。这将允许在升级前收到新令牌的应用继续使用这些令牌，而不需要刷新。
解决了减少写入的问题后，我们需要想出一个方法，以确保在升级窗口期间不丢失任何用户进行的撤回。这就需要创建一个队列系统（使用 [Cloudflare Queues](https://developers.cloudflare.com/queues/)！），在撤回事件发生后，在队列中记录该撤回事件的信息。这将使我们能够在切换到绿色版本后清空队列，重放在此时间窗口内发生的所有撤回事件。这一点至关重要，否则用户撤回的应用将不当地恢复其访问权限。
### 执行升级
#### 升级到 1.X
从操作的角度来看，我们首次升级到最新的 1.X 版本时，没有出现任何问题。我们的自定义数据库迁移运行速度超出预期，且没有用户影响。我们不得不进行硬切换，因为旧版本无法处理新版本创建的令牌。
切换后，我们发现刷新令牌错误急剧上升，而这种情况之前并没有出现。这是由于新版本中刷新无效行为的严格标准造成的；如果重用了刷新令牌，Hydra 将使整个访问和刷新令牌链失效。这对 Wrangler 和 MCP 客户来说是个问题。这些客户的请求量都很高，单个重用的刷新令牌将使整个会话失效。
我们通过向我们的 Worker 添加刷新令牌合并行为来减轻这一问题，Worker 会将 OAuth 流量路由到正确的目标。这使我们能够在请求达到 Hydra 之前临时缓存刷新令牌请求，因此如果我们检测到重试，可以在不使令牌失效的情况下直接响应。值得庆幸的是，Hydra 的 2.X 版本具有可配置的 "刷新令牌宽限期"，允许在不使整个链失效的情况下重试刷新令牌一段时间。
#### 升级到 2.X
由于多个小时的高用户影响是不可接受的，我们已经准备好蓝绿升级策略。从高层来看，这听起来简单；迁移将在生产数据库的副本上运行，然后在完成后切换和更新 Hydra 版本。然而，实际上还有更多的变动部分：
- 启用撤销重放捕获队列
- 将我们的数据库复制并恢复到新目标
- 目标数据清理 — 现有数据违反了更新版本引入的一些新约束，这可能会阻止迁移成功
- 在切换时，与 Hydra 服务同时进行两个额外的关键内部系统的切换，以防止任何错误
- 后切换监控和验证
我们选择在 Hydra 的请求量最低时进行升级窗口，以减少丢失令牌写入。除了某些超时调优外，我们的生产迁移在新数据库上运行良好：生产的净运行时间约为三小时。在迁移完成后，我们谨慎地推出新的 Hydra 服务版本，并与两个其他系统配置一起切换我们的系统以使用新的 SDK 版本。
切换流量后不久，我们观察到授权服务（依赖 Hydra 同意会话 API）的数据清理作业在清除 OAuth 策略数据时表现过于积极。经过调查，我们发现 Hydra 的一项迁移存在问题，导致某些有效的 OAuth 会话状态受损，从而导致迁移标记它们为无效。有效会话受损引起了 Hydra 和我们的授权服务之间的不一致，表现为 403 错误增加。为了减轻这一问题，我们进行了数据恢复，并开始改善 OAuth 授权行为，以消除对静态策略数据的依赖。
除了数据清理问题，还有一些更多的小修复，更加驱动于特定客户的行为，我们快速完成了这些修正。
随着 Hydra 版本的升级，OAuth 流量保持稳定，为我们的客户提供了更好的系统性能和可靠性。这一切也为我们在 6 月 3 日推出的 [自管 OAuth](https://developers.cloudflare.com/changelog/post/2026-06-03-public-oauth-clients/) 奠定了基础。
### 性能改进
完成这样的大规模升级后，回过头来看一些广泛的指标，总是令人欣慰和启发。我们在数据库迁移过程中收集了额外的指标，发现升级后性能有了显著改善。
#### 数据库
| 指标 | 近似值 |
|-------------------|------------|
| 更新的行数 | 132.5M |
| 插入的行数 | 114.7M |
| 临时字节 | 136.97GB |
| 事务提交 | 22.2k |
#### Hydra 性能
| 指标 (平均) | 之前 | 之后 | 变化 |
|------------------|-----------|---------------|-----------|
| API P95 | 185ms | 101ms | -45% |
| RSS 内存 | 888MB | 763MB | -14% |
| Go 堆分配 | 449MB | 271MB | -40% |
| 协程 | 4015 | 3076 | -23% |
| CPU | 1.07 cores| 0.67 cores | -37% |
### 面向所有人的自管 OAuth
向所有客户开放 OAuth 是扩展 Cloudflare 应用生态系统的一重要一步。如今，任何 Cloudflare 客户都可以创建自己的 OAuth 应用，并在 Cloudflare 上构建集成。我们对推出 Cloudflare 自管 OAuth 感到无比兴奋。
要开始使用，可以查看我们的 [文档](https://developers.cloudflare.com/fundamentals/oauth/) 或直接跳转到 [仪表板](https://dash.cloudflare.com/?to=/:account/oauth-clients) 的 OAuth 应用页面，创建你的第一个 OAuth 应用。
---
原文链接：[点击查看](https://blog.cloudflare.com/oauth-for-all/)
Cloudflare 在 OAuth 方面并不陌生。如果你使用过 Wrangler，或从合作伙伴如 PlanetScale 等进行过集成，那么你已经使用过了。然而，在此之前，第三方 OAuth 仅通过少量手动集成提供，无法广泛接入给开发者。这意味着构建自己集成的开发者不得不依赖 API 令牌，而这些令牌难以管理，并且不适合许多委托应用流。
在过去的一年中，我们吸收了越来越多的早期合作伙伴，同时改进了 Cloudflare OAuth 背后的同意、撤回和安全模型。但随着我们开发者平台的增长和代理工具对委托访问的需求不断增加，显然，向所有客户开放 OAuth 是我们平台成功的关键。
自管 OAuth 的推出，让开发者能够提供标准的 OAuth 流程，客户可以直接授权特定的访问权限，这使得构建 SaaS 集成、内部开发平台和代理工具变得更加容易，同时用户在访问授权、撤回和控制应用能够执行的操作上也更加清晰。
### 安全扩展生态系统
我们的早期 OAuth 解决方案足以支持少量经过严格管理的合作伙伴，但我们意识到，我们的权限模型、同意体验以及对潜在滥用向量的防范措施还不够成熟。
今年早些时候，我们 [更新了同意体验](https://blog.cloudflare.com/improved-developer-security/#improving-the-oauth-consent-experience)，使得请求访问的应用和所获得的权限变得更加清晰。同时，我们在仪表板上增加了撤回功能，方便开发者轻松控制哪些应用可以访问他们的数据，并使应用所有权更加可见，以防止 OAuth 钓鱼攻击。
对所有客户开放自管 OAuth 还需要对我们底层的 OAuth 引擎进行重大升级。这一过程需要进行大量的计划，在尽量减少用户中断的情况下，同时确保数据稳定和安全。
### 规划 OAuth 引擎的升级
几年前，我们部署了 [Hydra](https://github.com/ory/hydra)，一个开源 OAuth 引擎，作为 Cloudflare OAuth 的底层驱动力。虽然在使用量有限时，这项部署表现良好，但随着开发者平台的发展和代理工作流变得更加普遍，我们意识到需要进行重大升级，以便解锁新功能并提升性能。
在规划升级时，我们决定进行两次较小的顺序升级，而不是一次大升级。首先，我们将升级至最新的 1.X 版本，评估任何行为或性能的变化，然后再进行 2.X 的升级。
在升级规划过程中，我们意识到，即使是 1.X 的升级仍将影响客户，因为 Hydra 数据库需要进行广泛的模式迁移，这会：
1. 以一种方式创建索引，这将对关键表格声称独占锁，从而阻止活动用户进行重要的 OAuth 操作。
2. 向关键表中添加列，并移动其他列到新表中。
而且，我们使用的 Hydra 版本存在一个小问题，使得 SDK 会执行 `SELECT *` 操作，导致与模式变更产生反序列化问题。
为了避免用户受影响，我们重写了 SQL 迁移，使用 `CREATE INDEX CONCURRENTLY` 等功能，并构建了一个自定义版本的 Hydra，选择明确的列，而不是 `SELECT *`。
在规划好最新的 1.X 升级后，我们现在需要为更大规模的 2.X 升级制定计划。我们识别了三种潜在选择，并权衡了每种方案的优缺点。由于大版本升级带来的大量模式更改，一次就地升级对我们而言不可行。我们决定采用蓝绿策略，但除了简单地切换开关开始使用新版本外，还需要做更多工作。升级和迁移过程将需要数个小时，我们需要在这段时间内确保系统继续正常运行。
第一个蓝绿选项将涉及禁用对数据库的写入，阻止任何新的授权发生。这意味着在切换到绿色版本时不会丢失授予，但也意味着在升级期间，如果用户需要出于任何原因撤回应用的访问，将无法进行。
为了解决这些问题，我们想出了保持对数据库的写入启用的方法，代价是可能会在切换到绿色版本时失去一部分写入。我们采取的操作是：延长令牌的过期时间到数小时。这将允许在升级前收到新令牌的应用继续使用这些令牌，而不需要刷新。
解决了减少写入的问题后，我们需要想出一个方法，以确保在升级窗口期间不丢失任何用户进行的撤回。这就需要创建一个队列系统（使用 [Cloudflare Queues](https://developers.cloudflare.com/queues/)！），在撤回事件发生后，在队列中记录该撤回事件的信息。这将使我们能够在切换到绿色版本后清空队列，重放在此时间窗口内发生的所有撤回事件。这一点至关重要，否则用户撤回的应用将不当地恢复其访问权限。
### 执行升级
#### 升级到 1.X
从操作的角度来看，我们首次升级到最新的 1.X 版本时，没有出现任何问题。我们的自定义数据库迁移运行速度超出预期，且没有用户影响。我们不得不进行硬切换，因为旧版本无法处理新版本创建的令牌。
切换后，我们发现刷新令牌错误急剧上升，而这种情况之前并没有出现。这是由于新版本中刷新无效行为的严格标准造成的；如果重用了刷新令牌，Hydra 将使整个访问和刷新令牌链失效。这对 Wrangler 和 MCP 客户来说是个问题。这些客户的请求量都很高，单个重用的刷新令牌将使整个会话失效。
我们通过向我们的 Worker 添加刷新令牌合并行为来减轻这一问题，Worker 会将 OAuth 流量路由到正确的目标。这使我们能够在请求达到 Hydra 之前临时缓存刷新令牌请求，因此如果我们检测到重试，可以在不使令牌失效的情况下直接响应。值得庆幸的是，Hydra 的 2.X 版本具有可配置的 "刷新令牌宽限期"，允许在不使整个链失效的情况下重试刷新令牌一段时间。
#### 升级到 2.X
由于多个小时的高用户影响是不可接受的，我们已经准备好蓝绿升级策略。从高层来看，这听起来简单；迁移将在生产数据库的副本上运行，然后在完成后切换和更新 Hydra 版本。然而，实际上还有更多的变动部分：
- 启用撤销重放捕获队列
- 将我们的数据库复制并恢复到新目标
- 目标数据清理 — 现有数据违反了更新版本引入的一些新约束，这可能会阻止迁移成功
- 在切换时，与 Hydra 服务同时进行两个额外的关键内部系统的切换，以防止任何错误
- 后切换监控和验证
我们选择在 Hydra 的请求量最低时进行升级窗口，以减少丢失令牌写入。除了某些超时调优外，我们的生产迁移在新数据库上运行良好：生产的净运行时间约为三小时。在迁移完成后，我们谨慎地推出新的 Hydra 服务版本，并与两个其他系统配置一起切换我们的系统以使用新的 SDK 版本。
切换流量后不久，我们观察到授权服务（依赖 Hydra 同意会话 API）的数据清理作业在清除 OAuth 策略数据时表现过于积极。经过调查，我们发现 Hydra 的一项迁移存在问题，导致某些有效的 OAuth 会话状态受损，从而导致迁移标记它们为无效。有效会话受损引起了 Hydra 和我们的授权服务之间的不一致，表现为 403 错误增加。为了减轻这一问题，我们进行了数据恢复，并开始改善 OAuth 授权行为，以消除对静态策略数据的依赖。
除了数据清理问题，还有一些更多的小修复，更加驱动于特定客户的行为，我们快速完成了这些修正。
随着 Hydra 版本的升级，OAuth 流量保持稳定，为我们的客户提供了更好的系统性能和可靠性。这一切也为我们在 6 月 3 日推出的 [自管 OAuth](https://developers.cloudflare.com/changelog/post/2026-06-03-public-oauth-clients/) 奠定了基础。
### 性能改进
完成这样的大规模升级后，回过头来看一些广泛的指标，总是令人欣慰和启发。我们在数据库迁移过程中收集了额外的指标，发现升级后性能有了显著改善。
#### 数据库
| 指标 | 近似值 |
|-------------------|------------|
| 更新的行数 | 132.5M |
| 插入的行数 | 114.7M |
| 临时字节 | 136.97GB |
| 事务提交 | 22.2k |
#### Hydra 性能
| 指标 (平均) | 之前 | 之后 | 变化 |
|------------------|-----------|---------------|-----------|
| API P95 | 185ms | 101ms | -45% |
| RSS 内存 | 888MB | 763MB | -14% |
| Go 堆分配 | 449MB | 271MB | -40% |
| 协程 | 4015 | 3076 | -23% |
| CPU | 1.07 cores| 0.67 cores | -37% |
### 面向所有人的自管 OAuth
向所有客户开放 OAuth 是扩展 Cloudflare 应用生态系统的一重要一步。如今，任何 Cloudflare 客户都可以创建自己的 OAuth 应用，并在 Cloudflare 上构建集成。我们对推出 Cloudflare 自管 OAuth 感到无比兴奋。
要开始使用，可以查看我们的 [文档](https://developers.cloudflare.com/fundamentals/oauth/) 或直接跳转到 [仪表板](https://dash.cloudflare.com/?to=/:account/oauth-clients) 的 OAuth 应用页面，创建你的第一个 OAuth 应用。
---
原文链接：[点击查看](https://blog.cloudflare.com/oauth-for-all/)
评论
暂无评论。