Cloudflare 推出托管 OAuth，实现代理一键访问内部应用
Cloudflare AI··作者 Ann Ming Samborski
关键信息
托管 OAuth 可通过单击启用，使用 RFC 9728 进行发现，并支持 PKCE 流程（RFC 7636），使代理能动态注册并获取代表用户的 JWT 令牌。
资讯摘要
Cloudflare 推出了适用于 Access 的托管 OAuth，让 AI 代理可以安全访问受 Cloudflare Access 保护的内部应用程序。此前，代理无法处理登录重定向，现在它们可以通过遵循 OAuth 标准自动认证。该解决方案包括动态客户端注册（RFC 7591）、PKCE 授权流程（RFC 7636）和 JWT 令牌发放，与早期内部使用的 JWT 相同。
这使得人类和代理都能无缝访问应用。它特别适用于结合 Markdown for Agents 使用的 wiki 或 REST API 类应用。Cloudflare 还提供慷慨的免费层级，并计划通过 Organizations beta 支持跨账户身份桥接。
资讯正文
我们拥有数千个内部应用程序。其中一些是我们自己开发的，另一些则是由他人构建的软件的自托管实例。这些应用范围从几乎每个人都会使用的业务关键型应用，到侧边项目和原型。
所有这些应用都受到 Cloudflare Access 的保护。但当我们开始使用和构建代理（特别是用于编写代码以外的用途）时，遇到了一个障碍：人们可以访问 Access 后面的应用程序，但他们的代理却无法访问。
Access 位于内部应用前面。你定义策略后，Access 会将未认证的用户重定向到登录页面，让用户选择如何认证。
这种流程对人类用户非常有效。但所有代理看到的只是无法操作的登录页面重定向。
为代理提供对内部应用数据的访问权限至关重要，因此我们立即为自身内部使用实施了一个临时解决方案。我们修改了 OpenCode 的 web fetch 工具，使其在特定域名上触发 cloudflared CLI 打开授权流程以获取 JWT（JSON Web Token）。通过将此令牌附加到请求中，我们实现了对我们内部生态系统的安全、即时访问。
虽然这一方案仅是解决我们自身困境的权宜之计，但现在我们已弃用该临时方案，并为所有人彻底修复这个问题。目前处于公开测试阶段，每个 Access 应用均支持受管 OAuth。只需一键启用，即可让支持 OAuth 2.0 的代理轻松发现如何进行身份验证（RFC 9728），引导用户完成认证流程，并接收返回的授权令牌（与我们初始解决方案中的 JWT 相同）。
现在，无论是人类还是代理，整个流程都能顺畅运行。Cloudflare Access 提供慷慨的免费层级。此外，基于我们新推出的 Organizations 测试版，不久后您还将能够跨 Cloudflare 账户桥接身份提供商。
受管 OAuth 如何工作
对于某个受 Cloudflare Access 保护的内部应用，您只需一键启用受管 OAuth：
一旦启用受管 OAuth，Cloudflare Access 就充当授权服务器。它会返回 www-authenticate 头部，告诉未经授权的代理去哪里查找获取授权令牌的信息。代理会在 https://<your-app-domain>/.well-known/oauth-authorization-server 找到该信息。有了这个指引，代理就能遵循 OAuth 标准：
代理动态注册自身为客户端（这一过程称为动态客户端注册 — RFC 7591）
代理发起 PKCE（代码交换的证明密钥）授权流程（RFC 7636）
用户授权访问，从而授予代理一个令牌，代理可用其代表用户发起已认证的请求
以下是授权流程的样子：
如果这个授权流程看起来很熟悉，那是因为它正是 Model Context Protocol (MCP) 使用的方式。我们最初就在我们的 MCP 服务器门户中加入了对该功能的支持。
托管OAuth访问：一键让内部应用具备代理就绪能力
产品通过代理和控制多个MCP服务器的访问权限，使门户能够充当OAuth服务器。现在，我们将这一功能扩展到所有Access应用，让代理不仅能访问需要授权的MCP服务器，还能访问网页、Web应用和REST API。
让内部应用快速升级为代理就绪状态
将大量内部软件升级为支持代理是一项艰巨的任务。理论上，要实现代理就绪，每个内部和外部应用都应具备可发现的API、命令行接口（CLI）、精心设计的MCP服务器，并采用众多新兴的代理标准。
AI的采纳不能等到所有系统都重新改造完成。大多数组织拥有多年积累的应用程序积压清单。许多内部“应用”在被代理当作普通网站使用时表现良好。例如，对于一个内部维基来说，你真正需要做的只是启用Markdown for Agents功能，开启托管OAuth，代理就能获得读取受保护内容所需的一切。
为了在最广泛的内部应用中实现基础功能，我们使用托管OAuth。通过将Access置于遗留内部应用之前，你可以立即让它们具备代理就绪能力——无需代码更改，也无需重构。只需瞬间兼容。
这是用户的代理，无需服务账户和令牌
代理需要代表组织内的用户执行操作。我们看到的最大反模式之一是，人们为代理和MCP服务器配置服务账户，并使用静态凭证进行身份验证。这类做法在简单场景和快速原型中仍有其用途，Cloudflare Access也为此提供了服务令牌支持。
但当需要细粒度访问控制和审计日志时，服务账户方法很快就会暴露局限性。我们认为，代理执行的每一项操作都必须能清晰归因于发起它的人员，且代理只能执行其人类操作员同样有权执行的操作。服务账户和静态凭证会成为归属信息丢失的节点。那些将其所有操作都通过服务账户转发的代理容易陷入‘混淆代理人’问题，并导致审计日志看起来像是由代理自身发起的。
出于安全性和问责制考虑，代理必须使用能够明确表达用户与代理关系的安全原语。OAuth正是行业标准协议，用于请求和委托第三方访问权限。它为代理提供了一种方式，使其能够以用户身份调用你的API，所使用的令牌作用域限定于用户的标识，从而确保访问控制正确生效，审计日志也能准确归因于最终用户。
标准取胜：代理如何以及为何应在网络获取工具中采用RFC 9728
RFC 9728是使代理能够发现认证位置和方式的OAuth标准。它规范了该信息的存储位置和结构方式。这项RFC于2025年4月正式发布，并迅速被Model Context Protocol (MCP)采纳，如今MCP要求服务器和客户端均需支持该标准。
但除了MCP之外，代理应采用RFC 9728来应对一个更加关键的用例：向受OAuth保护的网页发起请求，以及向传统的REST API发起请求。
大多数代理都有一个用于基本HTTP请求的工具，这通常被称为“网页抓取”工具。它类似于在JavaScript中使用fetch() API，通常还会对响应进行一些额外的后处理。正是这个工具让你可以将URL粘贴到代理中，让代理去查找内容。
目前，大多数代理的网页抓取工具不会处理URL返回的www-authenticate头信息。底层模型可能会选择检查响应头并自行推断，但该工具本身并不会遵循www-authenticate头、查找/.well-known/oauth-authorization-server，并作为OAuth流程中的客户端执行操作。但它完全可以做到这一点，我们强烈认为它应该这么做！代理已经能这样做，以充当远程MCP客户端。
为了演示这一点，我们提交了一个草稿拉取请求，展示了Opencode中的网页抓取工具如何实现这一功能。在发起请求之前，该工具会先检查是否已拥有凭证；如果已有凭证，则直接使用它们发起初始请求。如果工具收到401或带有www-authenticate头的403响应，它会请求用户授权，进入服务器的OAuth流程。
以下是该OAuth流程的工作方式：如果你给代理一个受OAuth保护且符合RFC 9728规范的URL，代理会提示人类用户授权打开授权流程：
……将用户重定向到登录页面：
……然后跳转到一个提示用户授予代理访问权限的同意对话框：
一旦人类用户授予代理访问权限，代理就会使用所获得的令牌发起经过身份验证的请求。
从Codex到Claude Code再到Goose等任何代理都可以实现这一机制，而且这与Cloudflare没有特殊关联——全部基于OAuth标准构建。
我们认为这种流程非常强大，支持RFC 9728不仅能帮助代理完成基本的网页抓取请求，还能拓展更多能力。如果一个REST API支持RFC 9728（代理也支持），那么代理就具备了开始对该API发起身份验证请求所需的一切条件。如果该REST API还支持RFC 9727，客户端就能自动发现其REST API端点目录，从而无需额外文档、代理技能、MCP服务器或CLI即可执行更多操作。
这些机制在代理中都扮演着重要角色：Cloudflare本身提供了用于Cloudflare API的MCP服务器（基于Code Mode Wrangler CLI、Agent Skills和Plugin构建）。但支持RFC 9728有助于确保即使这些组件未预装，代理也能有清晰的发展路径。如果代理拥有一个可执行不受信任代码的沙箱环境，它可以直接编写并运行调用人类已授权API的代码。我们正在为Cloudflare自己的API开发这项支持，以帮助你的代理了解如何使用Cloudflare服务。
即将推出：跨多个Cloudflare账户共享同一身份提供商（IdP）
在 Cloudflare，我们自己的内部应用程序部署在数十个不同的 Cloudflare 账户上，这些账户都属于一个组织——这是一种新引入的管理方式，让管理员能够跨多个 Cloudflare 账户统一管理用户、配置并查看分析数据。
我们面临的问题与许多客户相同：每个 Cloudflare 账户都需要单独配置身份提供商（IdP），以便 Cloudflare Access 使用我们的身份验证服务。这对于整个组织来说至关重要——你不希望某个账户意外允许用户仅通过一次性验证码登录，而不是强制要求他们通过单点登录（SSO）进行认证。
为了解决这个问题，我们正在开发一种功能，使组织能够在多个 Cloudflare 账户之间共享同一个身份提供商，从而让组织可以指定一个主要的身份提供商，供所有账户使用。
当组织内新建 Cloudflare 账户时，管理员只需点击一次即可将该账户连接到主身份提供商，这样所有账户中的 Access 应用程序都可以由同一身份提供商保护。这避免了逐个账户手动配置 IdP 的繁琐流程，而这种手动操作对于拥有众多团队和个体各自独立账户的组织来说根本无法扩展。
下一步计划
在各类公司中，各个角色和业务职能的人都开始使用代理（agents）来构建内部应用，并期望他们的代理能访问内部应用中的上下文信息。我们正响应这一内部软件开发的显著增长趋势，致力于让 Workers 平台和 Cloudflare One 更好地协同工作，从而更轻松地在 Cloudflare 上构建并保护内部应用。
不久后将推出更多功能，包括：
- Cloudflare Access 与 Cloudflare Workers 之间更直接的集成，无需验证 JWT 或记住特定 Worker 所暴露的路由。
- wrangler dev --tunnel —— 一种便捷方式，让你在本地开发时将服务器暴露给他人，便于分享尚未部署的新项目。
- Cloudflare Access 和整个 Cloudflare API 的命令行界面（CLI）。
更多公告将在 2026 年代理周期间陆续发布。
现在即可为你的内部应用启用托管 OAuth
托管 OAuth 已面向所有 Cloudflare 客户开放测试版本。前往 Cloudflare 控制台启用此功能，为你的 Access 应用程序配置它。无论你是基于 Cloudflare Workers 构建的应用，还是托管在其他地方的应用，都可以使用这项功能。如果你还没有在 Workers 平台上构建过内部应用——这是你团队从零开始快速部署并保护生产环境的最佳途径。
来源与参考
收录于 2026-04-15