MCP 授权课：按现行规范，先回答“你是谁”

导语

MCP（Model Context Protocol）是 AI 应用与外部工具之间的标准连线：MCP host（如 Claude Code、Claude Desktop、VS Code）为每个 MCP server 创建一个 client，server 则暴露 tools、resources、prompts 三种原语。本文按 MCP 官方现行授权规范（2026-07-28 版；2026-10-06 核验 /specification/latest 重定向至此）解析其授权模型。（产品分析截止 2026-10-06）[1]

[1] [2]

授权仍是可选项

现行规范：Authorization is OPTIONAL。走 HTTP 的实现 SHOULD 遵循本规范；走 STDIO 的本地 server SHOULD NOT 走这套 OAuth 流程，而是从环境取凭据。注意这是 SHOULD NOT，不是技术上不能——本地是否安全，取决于进程隔离与凭据保管，规范把这部分留给了实现者。[2]

[2]

三方角色

现行规范设“Roles”一节，明确三方：受保护的 MCP server 是 OAuth 2.1 resource server；MCP client 是 OAuth 2.1 client，代表 resource owner 发起受保护资源请求；authorization server 负责在必要时与用户交互并签发 access token，可与 resource server 同机部署，也可以是独立实体——其实现细节超出本规范范围。“谁发 token”与“谁收 token”被正式拆开。[2]

[2]

Resource 与 audience 绑定

现行规范要求 client 按 RFC 8707 实现 Resource Indicators：在授权请求和 token 请求中都必须带 resource 参数，标识打算使用的 MCP server 的规范 URI；server 作为 resource server，必须验证 access token 是专门发给自己这个 audience 的，只能接受自家 authorization server 签发、供自家资源使用的 token，不得接受或转发任何其他 token。token 绑死资源，一令一地。[2]

[2]

DCR 已弃用

现行规范中，动态客户端注册（DCR）已被弃用，仅为向后兼容保留；authorization server 与 MCP client SHOULD 支持 OAuth Client ID Metadata Documents。client 发起授权流之前，必须经三者之一获得 client ID：Client ID Metadata Documents、预注册、或 DCR，按规范定义的优先级选择。[2]

[2]

Scope 挑战与 step-up

现行规范细化了权限不足时的处理：server 可在 401 的 WWW-Authenticate 头里带 scope 参数指引所需权限；当 token 因 scope 不足被拒绝时，server SHOULD 回 403 并带 insufficient_scope——注意这是 scope 不足的情形，token 无效或过期仍回 401。client 通过 step-up 流程用更大的 scope 集合重新授权后重试。[2]

需要区分两个不同的“人工”：step-up 重新授权走的是 OAuth 授权流程，代表用户行动的 client 按规范 SHOULD 尝试该流程——这个流程本身可能需要用户交互，授权协议允许且在某些情形下要求交互式授权；但这不等于“每一次工具调用都强制人工批准”。前者是授权协议内的机制，后者是 host 层的调用政策，两者不是一回事。[2]

[2]

401 握手

需要授权而 client 尚未证明时，server 回 HTTP 401，client 随后发起 OAuth 2.1 流程；token 走 Authorization header、不进 URI query string（OAuth 2.1 第 5 节要求，现行规范援引）。客户端须将返回的 iss 与预先记录的 issuer 精确比对；仅当授权服务器声明支持 iss 时，缺少该参数才必须拒绝响应（RFC 9207）。[2]

[2]

企业答案

企业扩展（独立版本）把组织的 IdP 变成权威决策者：员工一次登录，IdP 按组织策略决定可访问的 MCP server；按扩展文档的描述，在实现并支持该扩展的部署中，吊销在 IdP 层一次完成、所有 client 即时生效。未实测具体实现，不保证所有 MCP 部署都有此行为。个人场景逐个授权合理，企业场景制造摩擦与缺口。[3]

[3]

锐评

一、协议只标准化握手，不规定政策。“Roles”一节把 authorization server 的实现细节明确划出规范范围——MCP 连“谁发 token”都不替你定。这是诚实的设计：评估部署时，看 authorization server 那一侧，而不是线本身。

二、DCR 的弃用说明协议在收敛。从“动态注册一切”转向“先声明身份元数据”，信任从运行时协商前移到注册时声明。便利让位于可审计性，这是成熟协议的典型轨迹。

三、“以谁的名义”仍是原点。现行规范在 step-up 一节保留区分：“代表用户行动的 client”与“client_credentials client”走不同流程 [2]。冒充用户行动与应用自身行动，审计与吊销逻辑完全不同——选型先问这个，再问 scope。

四、授权协议不等于逐动作批准。scope 挑战与 step-up 是协议内的权限机制，其中 step-up 可能涉及用户交互；但“每一次工具调用都强制人工批准”是另一回事，属于 host 层政策。设计 agent 发布链路时，协议层（token 能否用）与政策层（这次调用批不批）必须分开——正如写稿、审核、发布签发不能是同一双手。

五、给实践者的四个问题（现行版）。authorization server 是谁（与 resource server 同机还是独立）？resource/audience 绑定是否落实？server 的 scope 挑战策略是什么（403 如何用）？client 注册走三种机制中的哪一种？答不上来，先别接生产数据。

[2]

尚不能断言

各 host/client 对现行规范的实现完整度（未实测）；

DCR 在实际部署中的弃用进度；

特定 MCP server 的实际安全水位（以其自身文档与审计为准）。