MCP OAuth 授权指南：为什么 Token 不能在工具链里一路透传

MCP OAuth 授权指南：为什么 Token 不能在工具链里一路透传

MCP Server 能读企业数据或执行动作后，鉴权不能停留在“有个 Bearer Token”。还要确认 Token 由谁签发、用于哪个资源、代表谁、允许什么，以及下游调用是否错误复用凭据。MCP 2025-11-25 授权规范强调资源发现、受众绑定和最小权限。

先区分三个角色

MCP Server 是 OAuth Resource Server，MCP Client 是 OAuth Client，Authorization Server 负责登录、同意和签发 Token。即使由同一组织部署，安全责任也要分开。

客户端怎样发现授权服务器

MCP Server 通过 Protected Resource Metadata 表明 Authorization Server。客户端再用 Server Metadata 或 OIDC Discovery 获取端点和能力。客户端仍需校验 HTTPS、来源与重定向；不同授权服务器的 client id 和 Token 必须隔离。

resource 参数绑定真正受众

客户端在授权和换取 Token 时携带 resource，明确目标 MCP Server；Server 必须验证受众并拒绝签发给其他资源的凭据。日志记录验证结果、主体、resource 与 scope，但不得保存完整 Token。

Token passthrough 为什么危险

常见错误是 MCP Server 收到用户 Token 后，原样转发给 CRM、云盘或内部 API。下游可能误以为这个 Token 已由可信中间层验证，或者恰好接受同一 issuer 的宽泛受众，于是上游权限被扩散到原本不该访问的系统。

正确做法是分开入站与出站授权。Server 用入站 Token 确定用户和工具权限；调用下游时，获取面向该 API 的独立凭据或使用受约束的 Token Exchange。两者有不同受众、scope 和审计。

Scope 要与工具动作对应

不要只定义一个 mcp.all。查询客户、导出报表、修改工单和发送邮件应使用不同 scope，并在具体工具参数确定后再次做资源级判断。读取权限不能隐式升级为写入，租户管理员也不应自动成为平台全局管理员。

PKCE、重定向与本地客户端

公共客户端无法安全保存 client secret，应使用 Authorization Code 加 PKCE，精确匹配 redirect URI、校验 state，并把 Token 放入系统安全存储。访问 Token 应短期有效，刷新凭据需轮换；401 与 403 也不能一律靠无限刷新解决。

在 AnyAIS 中建立工具授权边界

AnyAIS 可统一连接 MCP、模型与会话，但平台 Key、用户 OAuth Token 和下游凭据必须分层。工具调用关联用户、租户、sid、scope 与资源，敏感参数脱敏后审计。

上线前测试受众错误、scope 缺失、过期与撤销、跨租户资源、恶意重定向、重复授权和下游 Token 泄露。可用独立模型审阅权限矩阵是否遗漏路径，但安全结论必须由确定性授权测试和人工复核确认。

参考资料

• [MCP 2025-11-25 授权规范](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
• [MCP Security Best Practices](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices)
• [MCP 2025-11-25 版本变化](https://modelcontextprotocol.io/specification/2025-11-25/changelog)

如果你计划在 AnyAIS 接入企业 MCP 工具，可以先划分 resource、scope 和高风险动作，再实现 OAuth 发现、受众验证与下游独立授权。