Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

面向 Access 的托管 OAuth:一键让内部应用准备好对接 agent

原文:Managed OAuth for Access: make internal apps agent-ready in one click Source: https://blog.cloudflare.com/managed-oauth-for-access/

2026-04-14

我们 Cloudflare 内部有数千个应用。其中一些是我们自己构建的,另一些是别人构建的软件的自托管实例。它们涵盖几乎人人都用的关键业务应用,也包括各种边项目和原型。

这些应用都由 Cloudflare Access 保护。但当我们开始使用与构建 agent — 尤其是用于编码以外的用途时,我们撞到了一堵墙。人能访问 Access 后面的应用,他们的 agent 却不行。

Access 位于内部应用前面。你定义一条策略,然后 Access 会把未认证的用户引向登录页让他们选择如何认证。

Cloudflare Access 登录页示例

这套流程对人类来说效果很好,但 agent 看到的只是一个跳转到登录页的重定向,而它对此无能为力。

为 agent 提供内部应用数据访问太重要,我们立刻为自己的内部使用做了一个临时方案。我们修改了 OpenCode 的 web fetch tool,针对特定域名,触发 cloudflared CLI 打开一次授权流程来获取 JWT(JSON Web Token)。把这个 token 附加到请求上,我们就能安全、即时地访问内部生态。

这个方案是当时我们困境的临时答案,而今天我们要废弃这个临时手段,把这个问题为所有人解决。现已开放公测,每个 Access 应用都支持托管 OAuth。一键为某个 Access 应用启用,使用 OAuth 2.0 的 agent 即可轻松发现如何认证(RFC 9728),引导用户走完认证流程,并取回授权 token(就是我们最初方案中那种 JWT)。

现在,这套流程对人类和 agent 都顺畅。Cloudflare Access 有慷慨的 免费档。基于我们最近推出的 Organizations beta,你很快还能跨多个 Cloudflare 账户桥接身份提供方。

托管 OAuth 如何工作

对受 Cloudflare Access 保护的某个内部应用,你一键启用托管 OAuth:

启用之后,Cloudflare Access 充当授权服务器。它返回 www-authenticate 头,告知未授权的 agent 在哪里查询如何获取授权 token。它们能在 https://<your-app-domain>/.well-known/oauth-authorization-server 找到。有了这个指向,agent 就能遵循 OAuth 标准:

  1. Agent 动态把自己注册为客户端(称为 Dynamic Client Registration — RFC 7591),

  2. Agent 引导用户走 PKCE(Proof Key for Code Exchange)授权流程(RFC 7636)

  3. 用户授权访问,从而把一个 token 颁发给 agent,agent 凭此代表用户发起认证请求

授权流程大致是这样:

如果你觉得这个授权流程似曾相识,那是因为它正是 Model Context Protocol(MCP) 所使用的。我们最初是把这一支持构建到 MCP server portals 产品里,该产品代理并控制对许多 MCP 服务器的访问,让 portal 充当 OAuth 服务器。如今,我们把它带到所有 Access 应用,让 agent 不仅能访问需要授权的 MCP 服务器,还能访问网页、Web 应用与 REST API。

大规模升级你的内部应用,让它们准备好对接 agent

让那条长长的内部软件长尾都能与 agent 协作是项艰巨任务。原则上,要做到 agent 就绪,每个内部和外部应用最好都拥有可发现的 API、CLI、精心设计的 MCP server,并采纳众多新兴的 agent 标准。

但 AI 采用不能等所有这些都改造完。大多数组织都积压了多年的应用。而且许多内部“应用“在 agent 把它们当成普通网站处理时也能很好工作。对于像内部 wiki 这样的东西,你只需要启用 Markdown for Agents,开启托管 OAuth,agent 就拥有读取受保护内容所需的一切。

为了让最广泛的内部应用具备最基本的可用性,我们用托管 OAuth。把 Access 放到你那些遗留内部应用前面,你就让它们立刻具备 agent 就绪能力。无需改代码、无需改造,只需立刻兼容。

这是用户的 agent。无需服务账户与 token

Agent 需要在组织内代表用户行动。我们见过的最大反模式之一,就是有人为 agent 与 MCP server 配置服务账户,用静态凭证认证。这些在简单用例和快速原型中有其位置,Cloudflare Access 也支持 服务令牌(service tokens)。

但当需要细粒度访问控制和审计日志时,服务账户方法很快暴露其局限。我们认为 agent 执行的每个动作都必须能轻易归属到发起它的人,且 agent 只能执行其人类操作者同样有权执行的动作。服务账户与静态凭证会成为归属丢失的点。把所有动作通过服务账户“洗一遍“的 agent 容易出现 confused deputy 问题,并产生看起来像源自 agent 自身的审计日志。

为了安全与可问责,agent 必须使用能表达“用户—agent“关系的安全原语。OAuth 是请求与委派第三方访问的行业标准协议。它让 agent 能够代表用户与你的 API 通信,token 的作用域绑定到用户身份,从而正确应用访问控制,并把审计日志正确归属到最终用户。

标准是赢家:agent 该如何在 web fetch 工具中采用 RFC 9728

RFC 9728 是让 agent 能够发现“在哪里“以及“怎样“认证的 OAuth 标准。它规范了这些信息存放的位置与组织方式。该 RFC 于 2025 年 4 月正式发布,并很快被 Model Context Protocol(MCP)采纳,目前 要求 MCP 服务器和客户端都支持。

但在 MCP 之外,agent 应该为一个更基础的用例采纳 RFC 9728:对受 OAuth 保护的网页发起请求,以及对老老实实的 REST API 发起请求。

大多数 agent 都有一个发起基础 HTTP 请求到网页的工具,通常叫做 “web fetch” 工具。它类似于在 JavaScript 中使用 fetch() API,通常对响应做一些后处理。它就是让你把 URL 粘贴给 agent、让它去取内容的那个工具。

今天大多数 agent 的 web fetch 工具不会对 URL 返回的 www-authenticate 头做任何处理。底层模型也许会自行检视响应头并搞清楚状况,但工具本身不会跟随 www-authenticate 去查询 /.well-known/oauth-authorization-server,并在 OAuth 流程中作为客户端。但它可以,而且我们强烈认为它应该这么做!Agent 在做远程 MCP 客户端时已经在这么干了。

为了演示,我们提交了一个草稿 PR,改造了 Opencode 中的 web fetch 工具 来展示这一过程。在发起请求之前,改造后的工具先检查自己是否已有凭证;如果有,就用它发起初始请求。如果工具收到 401 或带 www-authenticate 头的 403,它会请求用户同意,把用户引导到该服务器的 OAuth 流程。

OAuth 流程是这样的。如果你给 agent 一个被 OAuth 保护并符合 RFC 9728 的 URL,agent 会请用户同意打开授权流程:

…把用户带到登录页:

…然后到一个征询同意的对话框,提示用户授予 agent 访问权限:

用户授予 agent 访问后,agent 用收到的 token 发起认证请求:

任何 agent — 从 Codex 到 Claude Code 到 Goose 等 — 都可以实现这一点,而且没有任何 Cloudflare 专有的内容。一切都基于 OAuth 标准。

我们认为这个流程很有价值,而支持 RFC 9728 能帮助 agent 不止于发起基本的 web fetch 请求。如果某个 REST API 支持 RFC 9728(且 agent 也支持),agent 就拥有开始对该 API 发起认证请求所需的一切。如果 REST API 还支持 RFC 9727,客户端就能自行发现 REST API 端点目录,无需额外文档、agent skills、MCP server 或 CLI 也能做更多事。

每一个对 agent 都有重要作用 — Cloudflare 自身就提供 面向 Cloudflare API 的 MCP server(用 Code Mode 构建)、Wrangler CLI 和 Agent Skills,还有一个 插件。但支持 RFC 9728 能确保即使没有任何这些预装,agent 也有清晰的前进路径。如果 agent 拥有一个 执行不受信任代码的沙箱,它可以直接编写并执行代码来调用用户授予其访问权限的 API。我们正在为 Cloudflare 自家 API 推进这一支持,帮你的 agent 学会如何使用 Cloudflare。

即将到来:跨多个 Cloudflare 账户共享同一身份提供方(IdP)

Cloudflare 内部应用部署到数十个不同的 Cloudflare 账户,这些账户都属于同一个 Organization — 新近推出 的一种方式,管理员可借此跨多个 Cloudflare 账户管理用户、配置并查看分析。我们和许多客户面临同样挑战:每个 Cloudflare 账户都得单独配置 IdP,以便 Cloudflare Access 使用我们的身份提供方。这一设置在整个组织中保持一致非常关键 — 你不希望某个 Cloudflare 账户不慎允许人们仅用一次性 PIN 登录,而绕过单点登录(SSO)。

为了解决这个问题,我们正在让你能跨 Cloudflare 账户共享同一身份提供方,允许组织指定一个主 IdP 用于其组织内的每个账户。

当组织内创建新的 Cloudflare 账户时,管理员只需一键就能配置到主 IdP 的桥接,让跨账户的 Access 应用都由同一个身份提供方保护。这就免除了逐账户手动配置 IdP 的繁琐,而那种方式对拥有许多团队和个人各自管理账户的组织而言无法扩展。

接下来

跨公司、跨各种角色与业务职能的人员,如今都在使用 agent 来构建内部应用,并期望他们的 agent 能从内部应用中获取上下文。我们正通过让 Workers Platform 与 Cloudflare One 更好地协作来回应内部软件开发的阶跃式增长 — 让构建并保护 Cloudflare 上的内部应用变得更容易。

更多内容即将到来,包括:

  • Cloudflare Access 与 Cloudflare Workers 的更直接集成,无需校验 JWT 或记住某个 Worker 暴露在哪条路由上。

  • wrangler dev –tunnel — 一种简便方式,在你构建新东西并希望在部署前让别人试用时,把你的本地开发服务器暴露给他人。

  • 面向 Cloudflare Access 与 整个 Cloudflare API 的 CLI 接口

  • Agents Week 2026 期间将有更多发布

为你的 Cloudflare Access 后内部应用启用托管 OAuth

托管 OAuth 现已对所有 Cloudflare 客户开放公测。前往 Cloudflare 仪表盘 为你的 Access 应用启用。你可以将其用于任何内部应用,无论是构建在 Cloudflare Workers 上的还是托管在别处的。如果你还没在 Workers 平台上构建内部应用 — 这是你的团队从零到生产部署(并保护)最快的方式。