Unlocking the Cloudflare app ecosystem with OAuth for all

TL;DR · AI 摘要
Cloudflare 推出自托管 OAuth,使开发者能更安全地构建 SaaS 集成和代理工具。
核心要点
- Cloudflare 推出自托管 OAuth,使开发者能更安全地构建 SaaS 集成和代理工具。
- OAuth 的权限模型、同意体验和防止滥用机制已得到显著改进。
- Cloudflare 使用 Hydra 作为 OAuth 引擎,并计划进行两次小规模升级以减少用户中断。
结构提纲
按章节快速跳转。
- §引言
Cloudflare 推出自托管 OAuth,以提升开发者平台的集成能力。
Cloudflare 之前仅对少数合作伙伴提供 OAuth,限制了开发者构建集成的能力。
自托管 OAuth 提供更清晰的权限控制、同意流程和撤销机制,提升安全性。
Cloudflare 使用 Hydra 作为 OAuth 引擎,并计划进行两次小规模升级以减少用户中断。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Cloudflare OAuth 升级
- 自托管 OAuth 的优势
- 更清晰的权限控制
- 更安全的同意流程
- 更易撤销的应用访问
- OAuth 引擎升级
- 使用 Hydra 引擎
- 两次小规模升级计划
金句 / Highlights
值得收藏与分享的关键句。
Self-managed OAuth 使开发者能够构建更安全、更可控的 SaaS 集成。
Cloudflare 的 OAuth 权限模型、同意体验和防止滥用机制已得到显著改进。
Cloudflare 使用 Hydra 作为 OAuth 引擎,并计划进行两次小规模升级以减少用户中断。
通过适用于所有用户的 OAuth 打开 Cloudflare 应用生态系统
2026-06-24
- Sam Cabell
- Mike Escalante
- Adam Bouhmad
- Nick Comer
6 分钟阅读
Cloudflare 提供的服务帮助运行了网络的 20%,但我们并不是独自完成的。我们平台上的开发人员也会使用其他公司提供的各种工具和服务。Cloudflare 为我们的平台提供了一个丰富的 API,使开发人员能够创建自动化、CI/CD 和集成,将基础设施的各个部分连接在一起。本月早些时候,我们宣布了自托管的 OAuth,使客户更容易创建和管理自己的 OAuth 客户端,以实现对 Cloudflare API 的委派访问。
Cloudflare 并不陌生于 OAuth。如果你使用过 Wrangler,或者使用过来自 PlanetScale 等合作伙伴的集成,那么你已经使用过它了。然而,直到现在,第三方 OAuth 仅通过少量手动上线的集成可用,并未广泛提供给开发人员。这意味着开发人员在构建自己的集成时,不得不依赖 API 令牌,而这些令牌更难管理,且不适合许多委派应用程序流程。
在过去的一年中,我们陆续引入了越来越多的早期合作伙伴,同时改进了 Cloudflare OAuth 的授权、撤销和安全模型。但随着我们的开发者平台不断壮大,以及代理工具对委派访问的需求增加,很明显,向所有客户开放 OAuth 对平台的成功至关重要。
通过自托管的 OAuth,开发人员现在可以提供一个标准的 OAuth 流程,客户可以直接授权范围访问,这使得构建 SaaS 集成、内部开发平台和代理工具变得更加容易,同时为用户提供了更清晰的授权、更简单的撤销以及对应用程序可以执行的操作的更多控制。
安全地扩展生态系统
虽然我们早期的 OAuth 解决方案对于少量经过仔细管理的合作伙伴来说已经足够,但我们意识到我们的权限模型、授权体验以及防止潜在滥用的方法还不够成熟。
今年早些时候,我们更新了授权体验,使用户更清楚地知道哪个应用程序正在请求访问权限,以及它将获得哪些权限。我们还在仪表板中添加了撤销功能,使开发人员能够轻松控制哪些应用程序可以访问他们的数据,并使应用程序的所有权更加可见,以防止 OAuth 钓鱼攻击。
向所有客户开放自托管的 OAuth 还需要对我们底层的 OAuth 引擎进行重大升级。这个过程需要大量的计划,以尽量减少对用户的影响,同时确保数据的稳定性和安全性。
规划我们 OAuth 引擎的升级
多年前,我们部署了 Hydra,一个开源的 OAuth 引擎,用于在后台驱动 Cloudflare OAuth。该部署在使用量有限时为我们提供了良好的支持,但随着开发者平台的增长和代理工作流程的普及,很明显我们需要进行一次重大升级,以解锁新功能并提高性能。
在我们规划升级时,我们决定进行两次较小的连续升级,而不是进行一次大规模的升级。首先,我们将升级到最新的 1.X 版本,评估任何行为或性能的变化,然后进行 2.X 的升级。
在我们的升级规划过程中,很明显,即使 1.X 的升级仍然会影响客户,因为 Hydra 数据库需要进行广泛的模式迁移:
- 以一种会占用关键表独占锁的方式创建索引,阻止活跃用户执行重要的 OAuth 操作
- 向关键表中添加了列,并将其他列移动到新表中
我们使用的 Hydra 版本还有一个小问题,即 SDK 会执行 SELECT * 操作,导致与模式变更相关的反序列化问题。
为了避免对用户造成影响,我们重新编写了 SQL 迁移脚本,使用诸如 CREATE INDEX CONCURRENTLY 等功能,并构建了一个自定义版本的 Hydra,使其选择显式列而不是使用 SELECT *。
随着最新的 1.X 升级计划已经制定,我们现在需要为更大规模的 2.X 升级制定计划。我们识别出了三个潜在选项,并权衡了每个选项的优缺点。由于主要版本升级带来的大量模式变更,我们发现原地升级对我们来说不可行。我们决定采用蓝绿部署策略,但仅仅切换开关以开始使用新版本是不够的,升级和迁移过程将需要多个小时,而在这段时间内,系统需要继续正常运行。
第一个蓝绿选项涉及禁用对数据库的写入,防止任何新的授权发生。这意味着在转换过程中不会丢失这些授权,但这也意味着除非用户已经拥有有效的凭证,否则无法使用现有的 OAuth 应用。此外,这还带来了另一个大问题:如果用户在升级期间出于任何原因需要撤销某个应用的访问权限,将无法实现。
为了解决这些问题,我们想出了一种方法,即在切换到绿色版本时保持数据库写入功能开启,但代价是会丢失部分写入。首先需要解决的是减少新令牌的写入数量。我们采取了一项操作措施:将令牌的过期时间延长到多个小时。这将允许在升级前接收到新令牌的应用在不刷新的情况下继续使用它们。
在减少写入的问题得到解决后,我们需要想出一种方法,以确保用户在升级期间执行的任何撤销操作都不会丢失。为此,我们创建了一个队列系统(使用 Cloudflare Queues!),在发生撤销事件后,会将有关该撤销的信息记录到队列中。这使我们能够在数据库切换到绿色版本后,排空队列并重放所有在升级期间可能会丢失的撤销事件。这一步非常关键,否则用户撤销的应用权限可能会被意外恢复。
执行升级
升级到 1.X
从操作角度来看,我们首次升级到最后一个 1.X 版本过程顺利,没有出现任何问题。我们自定义的数据库迁移脚本运行速度比预期还要快,且没有对用户造成任何影响。由于旧版本无法检查由新版本创建的令牌,因此我们不得不对新版本进行硬切换。
迁移后,我们发现刷新令牌错误的数量明显增加,这是之前从未见过的情况。这最终是由于新版本中刷新令牌失效行为更加严格所致;如果刷新令牌被重复使用,Hydra 将会失效整个访问令牌和刷新令牌链。这对 Wrangler 和 MCP 客户端来说是个问题。这些客户端的请求量都非常高,单个刷新令牌的重复使用会导致整个会话失效。
为了解决这个问题,我们在负责路由 OAuth 流量到正确目的地的 Worker 中添加了刷新令牌合并行为。这使我们能够在请求到达 Hydra 之前短暂地缓存刷新令牌请求,这样如果我们检测到重试,就可以直接跳过请求并作出响应,而不会使令牌失效。幸运的是,Hydra 2.X 版本提供了一个可配置的“刷新令牌宽限期”,这通过允许刷新令牌在一段时间内重试而不使整个链失效来解决了这个问题。
升级到 2.X
由于数小时的高用户影响是不可接受的,我们采用了蓝绿部署升级策略。从高层次来看,这听起来很简单;迁移将在我们生产数据库的副本上运行,然后在迁移完成后与新的 Hydra 版本一起切换。实际上,涉及的组件要多得多:
- 启用撤销重放捕获队列
- 复制并恢复我们的数据库到新的目标
- 针对性数据清理 —— 现有数据违反了新版本中引入的一些新约束,这可能会导致迁移失败
- 在 Hydra 服务以及两个其他关键的内部系统上同时执行切换,以防止任何错误
- 切换后的监控和验证
我们选择了一个 Hydra 每秒请求量最低的时间窗口,以尽量减少令牌写入的丢失。除了进行一些超时调整,我们的生产环境迁移在新数据库上运行良好:生产环境的总运行时间大约为三小时。迁移完成后,我们小心地推出了新的 Hydra 服务版本,同时更新了两个额外的系统配置,使我们的系统切换为使用新的 SDK 版本。
在切换流量后不久,我们发现授权服务中的一个数据清理任务(该任务依赖于 Hydra 的同意会话 API)在清理 OAuth 策略数据时过于积极。经过调查,我们发现其中一个 Hydra 迁移存在一个问题,导致某些有效的 OAuth 会话状态被损坏,从而导致迁移将这些会话标记为无效。这些被损坏的有效会话在 Hydra 和我们的授权服务之间造成了分歧,表现为 403 错误的增加。为了解决这个问题,我们进行了数据恢复,并开始对 OAuth 授权行为进行改进,以消除对静态策略数据的依赖。
除了数据清理问题外,还有一些其他小的修复,这些修复更多是针对特定客户端行为的,我们迅速完成了这些修复。
随着 Hydra 版本的升级完成,OAuth 流量保持稳定,系统性能和可靠性也得到了提升。这还使生产环境与我们新版本的 OAuth API 在预发布环境中已经验证的基础一致,为我们在 6 月 3 日的自托管 OAuth 发布铺平了道路。
性能改进
完成如此大规模的升级后,查看一些关于影响的总体指标总是令人感到欣慰且有启发性的。我们在数据库迁移过程中收集了额外的指标,并在升级完成后观察到了显著的性能提升。
数据库
指标
近似值
更新的行数
132.5M
插入的行数
114.7M
临时字节
136.97GB
事务提交次数
22.2k
Hydra 性能
指标(平均值)
升级前
升级后
变化
API P95
185ms
101ms
-45%
RSS 内存
888MB
763MB
-14%
Go 堆分配
449MB
271MB
-40%
Goroutines
4015
3076
-23%
CPU
1.07 核心
0.67 核心
-37%
所有客户均可使用自托管 OAuth
向所有客户开放 OAuth 是迈向更广泛的 Cloudflare 应用生态系统的重要一步。今天,任何 Cloudflare 客户都可以创建自己的 OAuth 应用程序,并在 Cloudflare 上构建集成。我们非常激动地推出面向所有客户的 Cloudflare 自托管 OAuth。
要开始使用,请查看我们的文档,或直接跳转到仪表板中的 OAuth 应用页面并创建您的第一个 OAuth 应用。
[if astro]>server-island-start<![endif]
开发者
API
安全
OAuth
开发者平台
代理
产品新闻
Cloudflare 媒体平台
身份