Cloudflare 为所有人推出了自我管理的 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 令牌，而 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 应用程序，除非他们已经拥有有效的凭据。它还带来了另一个大问题：如果用户需要撤销访问权限