MCP 2026-07-28 OAuth：Metadata、CIMD、Tool 授权

本文解决的问题

远程 MCP Server 为什么不能直接暴露公网？
MCP Authorization 和普通 API Key 有什么区别？
Protected Resource Metadata 是什么？
MCP Server 如何发现 Authorization Server？
Bearer Token、Scope、Resource Indicators 在 MCP 里怎么用？
如何避免不同用户调用到同一组高危 Tools？

适合谁读

已经把 MCP Server 从 stdio 迁移到 Streamable HTTP 的开发者
想把 MCP Server 部署到 VPS、Cloudflare Tunnel、企业内网的人
正在设计 Claude / Cursor 远程工具调用权限的人
关心 MCP OAuth、Token、Scope、Tool 权限边界的全栈开发者

一、本地 MCP 和远程 MCP 的安全边界完全不同

本文在 MCP 专题中的位置

这篇文章专门处理「远程 MCP Server 的认证与授权」。部署链路先看 MCP Streamable HTTP 实战；协议边界看 MCP 2026-07-28 协议指南；安全治理清单再看 MCP 安全最佳实践。

直接答案：MCP 2026-07-28 没有要求所有实现都必须使用 OAuth，但受保护的远程 Streamable HTTP Server 应按当前 Authorization 规范工作。 Server 发布 RFC 9728 Protected Resource Metadata；Client 用它发现 Authorization Server，授权与 Token 请求都带 RFC 8707 resource；授权响应按 RFC 9207 校验 iss；Client 注册优先走 CIMD 或预注册，DCR 只保留兼容。拿到 Token 也不等于能调用全部 Tools，Tool/resource/tenant 权限仍需 Server 每请求校验。

实战复核清单

给 MCP Server 加 OAuth 前，建议先明确：

哪些 Tools 是只读，哪些 Tools 有写入、删除、发送、转账、部署等副作用。
Scope 是否能精确限制到 tool 或 resource，而不是一个 token 通吃所有能力。
Token 过期、撤销、刷新失败时，Server 是否默认拒绝执行。
不同用户连接同一个远程 MCP Server 时，tools/list 是否会按权限裁剪。
审计日志是否记录授权主体、调用工具、资源范围和拒绝原因。

本地 MCP Server 的默认信任来自本机环境，远程 MCP Server 的默认假设必须是“不信任任何请求”。

在本地 stdio 模式下，Claude 或 Cursor 直接作为父进程启动 MCP Server，安全边界由操作系统内核保护。除非你的电脑本身被黑，否则没人能绕过客户端调用你的工具。

但当你把 MCP Server 迁移到远程 Streamable HTTP 后，情况发生了质变： Claude / Cursor → 网络 → 网关 / 代理 → MCP Server → 文件 / 数据库 / API

一旦接入公网或团队内网，你的 MCP Server 就面临以下核心风险：

未认证访问：任何知道你 URL 的人都能调用你的 Tools。
Token 泄露：如果只用简单的 API Key，泄露后权限难以精细化撤销。
越权调用：用户 A 可能会诱导 AI 调用本属于用户 B 的资源工具。
注入攻击：LLM 可能被 Prompt Injection 诱导，在未授权的情况下执行高危 Tool。

二、MCP Authorization 到底解决什么？

MCP Authorization 解决的不是“模型能不能调用工具”，而是“哪个 Client 可以代表哪个用户调用哪些受限工具”。

按 MCP 2026-07-28 当前规范，Authorization 是 HTTP-based transport 的可选能力；一旦 Server 声明自己是受保护资源，就应遵循规范定义的 OAuth 发现、resource/audience 和 issuer 校验流程。由于核心协议已 stateless，授权不是“连接建立时做一次”就结束，而应在每个受保护请求上持续验证。

我们需要区分三个层面的安全：

Authentication (认证)：验证“你是谁”（通常是 MCP Client 或背后的用户）。
Authorization (授权)：验证“你能调用什么”（即 Token 携带的 Scope）。
Tool Scope (工具边界)：在 MCP Server 内部，根据身份决定暴露哪些具体的 Tools 列表。

三、Protected Resource Metadata 是什么？

Protected Resource Metadata 可以理解为：MCP Server 告诉 Client，“如果你要访问我，应该去哪里拿授权”。

MCP Server 不应该让 Client 盲目猜测授权方式。规范要求 MCP Server 实现 OAuth 2.0 Protected Resource Metadata 机制，用于声明受保护资源的相关信息，特别是它所信任的授权服务器 (Authorization Servers) 列表。

这确保了 MCP 生态的互操作性：一个标准的 MCP Client (如 Claude 桌面端或某个自定义 Agent) 发现一个远程 Server 时，可以通过读取 metadata 自动引导用户完成 OAuth 流程。

四、Authorization Server Discovery 怎么走？

远程 MCP Server 应该通过标准 discovery 机制告诉 Client 授权入口，而不是把 token endpoint 写死在文档里。

当前规范要求 Client 同时支持两类 Protected Resource Metadata 发现路径：

401 Unauthorized 挑战：Server 可在 WWW-Authenticate 里返回 resource_metadata URI，并可同时给出当前操作所需的 scope；
RFC 9728 well-known 路径：如果没有可用的 challenge metadata URL，Client 必须按 MCP endpoint path 和站点 root 的 well-known URI 顺序尝试发现。

拿到 Protected Resource Metadata 后，Client 再读取其中的 authorization_servers，并使用 RFC 8414 / OpenID Connect Discovery 获取 Authorization Server metadata。Client ID、Token 和注册状态必须按 Authorization Server 隔离，不能默认跨 issuer 复用。

五、2026-07-28 新增的两条硬边界：issuer validation 与 CIMD

1. RFC 9207 issuer validation

Client 在把用户重定向到 Authorization Server 前，应保存从经过验证的 metadata 得到的 issuer。授权响应如果携带 iss，Client 必须按 RFC 9207 与之前记录的 issuer 做严格比较；声明支持 authorization_response_iss_parameter_supported=true 却没有返回 iss 时，应拒绝该响应。这样可以降低 Authorization Server mix-up 风险。

2. Client ID Metadata Documents（CIMD）优先于新建 DCR 依赖

当前规范把 Client 注册优先级放在 CIMD / 预注册，再到 Dynamic Client Registration。DCR 仍可用于向后兼容，但已经 deprecated。新 Client 不应把“服务端必须开放任意 DCR”当成 MCP 互操作性的前提。

六、最小远程 MCP 认证架构

为了实现安全的远程调用，一个典型的架构如下：

Claude / Cursor (Client) ↓ 携带 Access Token 发起 HTTP 请求 ↓ 远程 MCP Server (Resource Server) ↓

校验 Token 有效性
校验 Scope (是否包含 tool:call 权限)
校验 Resource Indicator (Token 是否签发给本服务器) ↓ Tool 层逻辑校验 (根据 User ID 隔离环境) ↓ 执行具体工具并返回结果

六、为什么 API Key 不够？

API Key 适合个人实验，不适合多用户、远程、可撤销、可审计的 MCP 服务。

在生产环境下，API Key 存在显著弊端：

无法表达用户身份：Key 通常是静态的，难以区分是哪个终端用户在调用。
难以细分 Tool Scope：你很难为一个 API Key 设置“只能调用只读工具”的动态权限。
泄露风险：API Key 一旦泄露，除非更换整个 Key，否则无法针对特定 session 撤销。
审计粒度：OAuth Token 可以绑定更丰富的元数据，方便在日志中追踪具体的调用链路。

七、Tool Scope 怎么设计？

远程 MCP Server 不能只验证“用户是否登录”，还要验证“用户能不能调用这个 Tool”。

我们应该在代码中实现基于 Scope 的工具暴露逻辑。例如：

read:files: 仅允许调用 list_directory 和 read_file。
write:files: 允许调用 write_file 和 delete_file。
admin:db: 允许执行 drop_table 等高危操作。

在 MCP Server 的 listTools 处理器中，你应该根据请求上下文中的身份信息，动态返回当前用户有权使用的工具子集，而不是一把抓地全部暴露。

八、Resource Indicators：Token 不能到处用

远程 MCP Server 的 Token 不应该在多个服务之间随意复用。

根据 MCP 规范对 OAuth 2.1 的引用，客户端在请求授权和获取 Token 时，应该包含 resource 参数（Resource Indicators）。这意味着授权服务器签发的 Token 是带有“受众”标记的。

一个签发给 https://api.xbstack.com/mcp 的 Token，如果不包含对 https://internal.tools.local/mcp 的授权，那么后者应该拒绝该请求。这有效防止了 Token 被中间人拦截后用于攻击其他敏感的 MCP 服务。

九、常见报错与常见坑 (Error Logs)

1. Error: HTTP 401 Unauthorized

现象：Client 无法连接远程 Server。原因：通常是 Token 缺失、过期，或者 Server 要求的 WWW-Authenticate 挑战格式不符合 Client 预期。

2. Error: Insufficient Scope

现象：连接成功，但 listTools 返回空列表，或调用特定工具时报错。原因：Token 权限不足。请检查 OAuth 授权时申请的 scopes 是否覆盖了所需的 Tool 权限。

3. 风险：多租户业务状态泄露

陷阱：虽然 MCP 2026-07-28 核心协议已经 stateless，Server 仍可能把购物篮、审批、游标、上传任务或 Tool 缓存错误地放进进程级全局内存，导致用户 A 的业务状态干扰用户 B。对策：协议请求保持 stateless；需要跨请求保存的业务状态使用显式、不可猜测的业务 handle，并绑定 principal、tenant、resource 与过期策略。不要重新发明一个没有授权边界的“隐形 Session”。

十、实战建议：远程 MCP Server 的安全底线

远程 MCP 一旦暴露到公网或团队网络，就不能把“只有 AI Client 知道这个 URL”当成安全控制。只要 Server 连接到文件、数据库、消息发送、部署或其他有副作用的 Tool，未授权访问和 Token 误用都会直接放大为真实系统风险。

我建议你的远程 MCP Server 至少做到：

强制 HTTPS 传输，禁止明文 HTTP。
使用 Bearer Token 校验，哪怕初期只是静态 Token 验证（作为过渡）。
实现 Tool 级别的权限校验逻辑。
开启详细的审计日志，记录每个 Tool 被谁调用、输入参数是什么。

FAQ

MCP Server 一定要用 OAuth 吗？

本地 stdio Server 不一定需要；远程 MCP Server 如果涉及用户资源、私有数据、企业工具或生产系统，就应该使用 OAuth 或等价的认证授权机制。

API Key 可以替代 OAuth 吗？

个人实验可以，但多用户、可撤销、可审计的远程服务不建议只用 API Key。

MCP Authorization 和 Tool Scope 是一回事吗？

不是。Authorization 解决“谁可以访问 MCP Server”，Tool Scope 解决“这个用户可以调用哪些工具”。

远程 MCP Server 能不能只靠 Cloudflare Access？

可以作为第一层网络与身份边界，但 MCP Server 内部仍然要做 Tool Scope 和资源权限判断。

为什么要校验 resource / audience？

为了防止一个 Token 被拿去访问本不该访问的 MCP Server。

继续阅读

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单订阅

小白 / Xiaobai

MCP 2026-07-28 OAuth 认证：Protected Resource Metadata、CIMD 与 Tool 授权

本文解决的问题

适合谁读

一、本地 MCP 和远程 MCP 的安全边界完全不同

本文在 MCP 专题中的位置

实战复核清单

二、MCP Authorization 到底解决什么？

三、Protected Resource Metadata 是什么？

四、Authorization Server Discovery 怎么走？

五、2026-07-28 新增的两条硬边界：issuer validation 与 CIMD

1. RFC 9207 issuer validation

2. Client ID Metadata Documents（CIMD）优先于新建 DCR 依赖

六、最小远程 MCP 认证架构

六、为什么 API Key 不够？

七、Tool Scope 怎么设计？

八、Resource Indicators：Token 不能到处用

九、常见报错与常见坑 (Error Logs)

1. Error: HTTP 401 Unauthorized

2. Error: Insufficient Scope

3. 风险：多租户业务状态泄露

十、实战建议：远程 MCP Server 的安全底线

FAQ

MCP Server 一定要用 OAuth 吗？

API Key 可以替代 OAuth 吗？

MCP Authorization 和 Tool Scope 是一回事吗？

远程 MCP Server 能不能只靠 Cloudflare Access？

为什么要校验 resource / audience？

继续阅读

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

继续阅读

AI 工程周报

问题、验证与勘误