解锁Cloudflare应用生态系统的OAuth功能 2026-06-24 阅读时间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应用。这还带来了另一个重大问题：如果用户因任何原因需要撤销对某个应用的访问，