MCP Authorization：基于 OAuth 2.1 的远程工具授权框架
MCP 在 2025-03-26 规范中加入基于 OAuth 2.1 的授权框架，用于 HTTP 传输下的受限服务访问。
MCP Authorization specification mcp agent-protocol security MCP 在 2025-03-26 规范中加入基于 OAuth 2.1 的授权框架，用于 HTTP 传输下的受限服务访问。
1. 项目定位
MCP Authorization 是 Model Context Protocol 在传输层定义的授权能力。2025-03-26 版本加入较完整的 OAuth 2.1 框架，用于让 HTTP 客户端代表资源所有者访问受保护的 MCP 服务；授权本身对实现仍是可选项。[S1][S2]
2. 核心机制
规范要求支持授权的 HTTP 实现采用带安全措施的 OAuth 2.1，并通过授权服务器元数据发现端点；它还建议支持动态客户端注册。授权码流程适合代表用户访问，客户端凭证适合应用自身访问。[S1]
3. 适用边界
该流程针对 HTTP 类传输。规范明确指出，STDIO 传输不应套用这套授权，而应从环境中取得凭据。它解决的是客户端如何获得受限服务访问权，不替代服务内部的业务角色、字段权限和审计策略。[S1]
4. 发现与连接
客户端先根据 MCP 服务地址确定授权基础地址，再读取标准元数据；若服务未提供元数据，旧版规范定义了默认授权、令牌和注册端点作为回退。实现者应固定校验目标地址，避免发现过程被重定向到恶意站点。[S1]
5. 部署路径
服务端先梳理资源与最小权限范围，配置授权服务器和元数据，再让测试客户端完成登录、换取令牌和刷新。客户端应区分公开与机密类型，安全保存令牌，并把回调地址、状态参数和 PKCE 纳入测试。
6. 权限设计
令牌可用不等于所有工具都可调用。服务端仍需在每次请求时检查主体、受众、范围和资源归属；高风险写操作应使用更窄的权限并保留确认步骤。不同租户之间不得复用缓存的授权结果。
7. 主要风险
常见风险包括回调地址配置过宽、令牌泄漏、范围设计过大、混淆第三方授权服务器，以及把身份认证误当成业务授权。自动注册虽然降低接入成本，也需要限制客户端元数据和重定向地址的可信范围。
8. 评估方法
测试应覆盖正常登录、拒绝授权、过期令牌、刷新失败、错误受众、跨租户访问和撤销后的再次调用。还要验证日志不记录完整令牌，错误响应不泄露敏感配置，并对每个高风险工具执行越权用例。
9. 采用建议
实现时必须锁定所支持的 MCP 规范版本，因为授权设计在后续版本可能继续调整。优先复用成熟 OAuth 组件，不自行发明令牌格式；上线前让身份、安全和业务权限负责人共同审核端到端流程。
10. 来源与更新时间
本文以 2025-03-26 规范为研究对象，更新截至 2026-08-07；新项目应另行核对最新版本的差异。