MCP 授权机制拆解：OAuth 2.1 落进 MCP 的完整流程（2026-07-28 规范版）

MCP 的远程服务器要接真实用户与真实数据，授权就是绕不开的一层。2026-07-28 规范版的 Authorization 章节（2026-09-03 核对）把这件事标准化：MCP 不发明新协议，而是站在 OAuth 2.1 草案与一排 RFC 的肩膀上，规定了一个选择性子集——MCP 服务器扮演什么角色、客户端如何发现授权服务器、怎么注册、token 怎么带、scope 怎么最小化。本文按实现者的视角把规范拆成可执行的规则，所有 MUST / SHOULD 均引自规范原文。

1. 先分清：谁扮演什么角色，谁需要 OAuth

规范的角色映射非常干净：

授权是可选能力，但按传输方式区别对待：

• HTTP 传输的实现 SHOULD 遵循本规范；
• stdio 传输的实现 SHOULD NOT 遵循——凭据从环境变量获取（与《MCP 调试实战：Inspector、日志规范与连接问题排查链》里"环境变量继承受限"的机制是同一套）；
• 其他传输 MUST 遵循各自协议的安全最佳实践。

2. 标准基座：MCP 用了 OAuth 生态的哪几个件

规范声明自己基于以下标准的选择性子集（完整清单引自规范）：

3. 发现与注册：两条 MUST 与三种注册方式

发现：受保护 MCP 服务器 MUST 实现 RFC 9728，通过 Protected Resource Metadata 声明自己的授权服务器；客户端 MUST 使用该元数据完成发现，再对授权服务器做元数据发现拿到端点与能力。

注册：发起授权前，客户端 MUST 通过三种机制之一获得 client ID——Client ID Metadata Documents、预注册、或动态客户端注册（RFC 7591）。注意规范给动态注册的定性：已弃用（deprecated），仅为兼容不支持 Client ID Metadata Documents 的授权服务器而保留；新实现 SHOULD 走 Client ID Metadata Documents。

4. 授权响应校验：iss 的四种组合

客户端在重定向用户代理前，必须把"已验证元数据里的 issuer"与 PKCE verifier 存进同一条请求记录；响应校验依赖这条记录的真实性。授权服务器 SHOULD 在响应里带 iss 参数（RFC 9207），并用元数据的 authorization_response_iss_parameter_supported 声明。客户端的处理规则（规范原表）：

三个细节：比较不得做大小写折叠、默认端口省略、尾斜杠或百分号规范化；规范预告未来版本会把 iss 从 SHOULD 升级为 MUST，建议实现者现在就发并校验；校验同样适用于错误响应——iss 不匹配时客户端 MUST NOT 展示或使用响应里的 error / error_description / error_uri（防注入）。

5. resource 参数：token 只为这个服务器签发

客户端 MUST 实现 RFC 8707 的 resource 参数：授权请求与 token 请求都要带，取值为目标 MCP 服务器的 canonical URI（小写 scheme 与 host；实现方 SHOULD 接受大写以稳健互操作），且无论授权服务器是否支持都必须发送。

合法 canonical URI 示例（引自规范）：
https://mcp.example.com/mcp
https://mcp.example.com
https://mcp.example.com:8443
https://mcp.example.com/server/mcp（路径用于区分服务器时）

无效示例：
mcp.example.com                （缺 scheme）
https://mcp.example.com#fragment  （含 fragment）

规范还建议：带尾斜杠与不带在 RFC 3986 下都合法，但统一用无尾斜杠形式以获得更好的互操作性（除非尾斜杠对该资源有语义）。授权请求中的形态如 &resource=https%3A%2F%2Fmcp.example.com。

6. token 使用红线

请求侧（MCP 客户端）：

GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

• token 必须放在 Authorization: Bearer 请求头，且客户端到服务器的每个请求都要带；
• token MUST NOT 出现在 URI query string。

服务器侧（MCP 服务器 = 资源服务器）：

• 按 OAuth 2.1 校验 token，并 MUST 校验 audience（RFC 8707 §2——这个 token 是不是签给本服务器的）；
• 无效或过期 token 返回 HTTP 401；
• 客户端 MUST NOT 向 MCP 服务器发送非其授权服务器签发的 token；
• 服务器 MUST NOT 接受或转发任何其他 token——这是 Token Passthrough 反模式（见《MCP 安全指南：官方 8 类攻击面与缓解清单》）在授权规范里的正式条款。

7. scope：最小化与 step-up

初始授权的 scope 选择优先级（客户端 SHOULD 遵循最小权限）：

1. 首选 401 响应 WWW-Authenticate 里的 scope（RFC 6750 §3）；
2. 没有则用 Protected Resource Metadata 的 scopes_supported（未定义则省略 scope 参数）。

两条 MUST 级约束：客户端 MUST NOT 假定挑战 scope 与 scopes_supported 有任何集合关系（子集/超集都可能），挑战里的 scope 对当前操作权威；scopes_supported 的定位是基础功能的最小集，额外权限通过 step-up 授权流增量获取。服务器返回 401 时的标准形态：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
 scope="files:read"

8. 运行期权限不足与错误码

运行期持 token 但权限不足：服务器返回 403 + WWW-Authenticate 带 error="insufficient_scope"、所需最小 scope 集合、以及 resource_metadata（与 401 响应保持一致）。客户端据此走 step-up：向用户/授权服务器补请求所需 scope，重授权时 SHOULD 保留既有 scope，避免丢掉其他操作已获权限。

refresh token 的配套规则也值得记：客户端 MUST 保密传输与存储、SHOULD 在客户端元数据 grant_types 里声明 refresh_token、可在授权服务器 scopes_supported 含 offline_access 时请求之；并且 MUST NOT 假定一定会签发——决定权在授权服务器；服务器侧则 SHOULD NOT 把 offline_access 放进 WWW-Authenticate 或 scopes_supported（它不是资源访问需求）。

9. 常见错误与排查

• stdio 服务器套 OAuth：规范明确 stdio SHOULD NOT 走这套——凭据走环境变量，别把 HTTP 授权流程硬套给本地进程。
• token 进了 query string：规范明令禁止；只走 Authorization 头。
• 漏发 resource 参数："授权服务器不支持就不发"是错的——MUST 发，且用 canonical URI。
• audience 不校验：不校验 audience 就接受了可能面向别的资源的 token，正是 Token Passthrough 类风险的入口。
• iss 比较前做规范化：大小写折叠、尾斜杠、端口省略都会破坏比较语义——简单字符串比较。
• 把 scopes_supported 当全量目录请求：它是基础最小集，额外权限走 step-up。

10. 下一步

• 授权之外的实施层攻击面：《MCP 安全指南：官方 8 类攻击面与缓解清单》。
• 调试授权与连接问题：《MCP 调试实战：Inspector、日志规范与连接问题排查链》。
• 协议本体与三层架构：《Model Context Protocol 完全指南：MCP 工作机制与实战》。