MCP Server 鉴权边界：不要把用户身份、工具权限和服务凭证混在一起
MCP Server 接入生产系统时，最容易出问题的不是能否拿到 token，而是身份与权限边界被混用。本文给出一套可落地的鉴权分层、令牌交换、审计与故障处理方法。
本文要点
- 主题聚焦：AI、AI Agent、MCP
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
把一个 MCP Server 接到生产 API 时，很多团队的第一反应是给 Server 配一个高权限 API Key。Demo 很快能跑通，但之后所有调用都会带着同一把钥匙：谁发起、可以访问什么、出了问题该找谁，全部失去边界。模型、客户端、Server 和下游业务系统之间的身份并不相同，必须明确拆开。
先区分四种身份
一个可靠的设计至少涉及四类主体：最终用户、MCP 客户端、MCP Server 和下游服务账号。最终用户决定业务权限，例如能否查看某个项目的数据；客户端代表某个已注册的应用；Server 是执行工具调用的中间层；服务账号只负责连接数据库、工单系统或内部 API。把它们都塞进一个 bearer token，会让最小权限和审计都无法成立。
推荐的原则是：用户身份用于授权，客户端身份用于准入，服务账号用于网络连接。Server 不应该把自己的服务凭证伪装成用户身份，也不应该相信客户端传来的任意 tenantId。每次工具调用都要有可验证的调用者上下文。
一条可执行的调用链
可以把请求拆成下面五步：
- 用户登录 MCP 客户端，客户端取得短生命周期的用户会话。
- 客户端与 MCP Server 建立连接时，Server 校验客户端身份、回调地址和受众。
- Server 将用户会话转换为内部可验证的授权上下文，其中包含用户 ID、租户、角色、允许的 scope 和过期时间。
- 工具执行前，根据工具名和输入资源再次做授权，例如
tickets.read不能自动拥有tickets.write。 - Server 使用自己的低权限服务账号访问下游系统，同时把授权上下文和关联 ID 写进审计事件。
这里的关键是第三步。下游服务不必信任原始客户端 token，也不必理解 MCP 协议；它只需要验证由内部身份服务签发的上下文。这样可以在一个地方统一处理租户、角色、禁用用户和会话撤销。
scope 必须跟工具能力对应
不要定义一个笼统的 mcp:access。把 scope 按风险拆分，例如：
repo.read
repo.pull-request.write
incident.read
incident.comment.write
analytics.query
analytics.export
工具注册时声明自己需要的 scope；执行器在真正发出下游请求前再判断一次。这样即使模型被 prompt injection 诱导去调用高风险工具，也会在授权层被拒绝。对写操作还应增加用户确认或策略审批，不能把模型生成的一段自然语言直接当作授权。
凭证处理的常见错误
第一，不把长效密钥放进工具参数、模型上下文或日志。模型可能复述上下文，调试日志也可能被更宽的人员看到。第二，不让一个公共 Server 共用管理员数据库账号。第三，不把 token 的有效期设置得和用户登录会话一样长；执行工具通常只需要几分钟的权限。
如果必须代表用户访问第三方服务，采用受众受限、短生命周期、可撤销的令牌，并记录令牌是为哪个工具、哪个资源和哪个会话签发的。令牌交换失败时返回可操作的错误，例如“当前连接没有 analytics.export 权限”，不要返回内部密钥或完整上游响应。
上线前验证清单
- 用普通用户、管理员、被禁用用户分别调用同一工具，确认结果不同且可解释。
- 修改工具输入中的 tenantId，确认不会跨租户读取数据。
- 模拟过期 token、撤销会话和下游服务超时，确认不会降级为匿名高权限访问。
- 检查日志，确认没有原始 token、密码、完整身份证号或导出数据。
- 对所有写工具要求显式 scope，并记录谁确认了本次操作。
MCP 鉴权的目标不是让调用更复杂，而是让每一次工具执行都能回答三个问题：谁请求的、为什么被允许、实际访问了什么。把这些问题在设计阶段回答清楚，后续接入更多工具时才不会不断补安全洞。
延伸阅读
Related