MCP 服务器凭据怎么管：令牌不进上下文、最小权限与轮转机制

MCP 服务器的凭据风险不在传输层，而在「谁拿着令牌、令牌被谁看见」。按 Model Context Protocol 官方安全实践，有五条不能打折的硬规则：禁止令牌透传、必须校验受众、凭据不进模型上下文、按工具分域最小授权、以及可审计的轮转与清理。做到这五条，绝大多数 MCP 凭据事故就不会发生。

最危险的反模式：令牌透传

「令牌透传」指 MCP 服务器接受客户端送来的令牌，不校验它是不是发给自己的，就原样转发给下游 API 。官方规范明确禁止这种做法，因为它同时带来四类破坏：

• 绕过安全控制：下游 API 的限流、请求校验往往依赖令牌受众，透传会让这些控制形同虚设。
• 审计链断裂：下游日志里看到的是别人的身份，出事后无法定位到底是哪个客户端发起的。
• 信任边界被打破：一个服务被攻破，攻击者可以拿同一个令牌访问其他所有接受它的服务。
• 混淆副手问题：下游误以为令牌已被 MCP 服务器校验过，从而放松自己的检查。

五条硬规则

凭据到底该放在哪

把凭据分层，是避免它流进模型上下文的前提。推荐的三层结构是：

• 服务器自身的服务端密钥：放在密钥管理服务或环境变量里，由服务器启动时读取，永不作为参数传给工具、永不出现在工具返回值里。
• 按用户维度的第三方令牌：用户授权后拿到的下游令牌，缓存在服务端加密存储中，键名绑定用户标识，并配置明确的过期与淘汰策略，避免复用已失效令牌。
• 会话层标识：MCP 的会话标识只用于路由与恢复连接，不能当作身份凭证使用。

最容易出问题的是第二层：为了省事把用户令牌塞进上下文或工具参数，模型一旦被提示注入诱导，就会把令牌当作普通文本输出。正确做法是令牌只在服务端内部流转，工具对模型暴露的永远是「已授权」这类布尔状态或一个不透明的资源句柄。

缓存与轮转的最小实现

# 缓存键绑定用户标识，避免越权命中
cache_key = f"token:{user_id}:{downstream_name}"

def get_downstream_token(user_id, downstream):
    tok = cache.get(cache_key)
    if tok and not is_expired(tok):
        return tok            # 命中且未过期
    tok = refresh_with_refresh_token(user_id, downstream)
    cache.set(cache_key, tok, ttl=tok.expires_in * 0.8)  # 提前过期，留出刷新窗口
    return tok

# 日志脱敏：只写标识，不写值
log.info("downstream token refreshed", extra={"user": user_id, "downstream": downstream})

日志与会话的两条红线

• 日志只能有标识不能有值：Authorization 头、令牌、授权码、密钥一律不落日志；结构化日志中的敏感字段统一脱敏，排查需要时用关联 ID 到内部系统查详情。
• 会话标识不可信：把它当成普通不可信输入处理，不要基于它做授权判断，认证状态变化时重新生成，并在服务端校验其生命周期。使用安全的非确定性随机会话标识，避免可猜测的顺序 ID；存储或传输与会话相关的数据时，把用户标识与会话标识组合成键，这样即便会话标识被猜到也无法冒充他人。

上线前检查清单

相关阅读：MCP 远程服务器的 OAuth 授权：从零到可用、MCP 安全风险全景：提示注入、权限边界与 URL 校验、MCP 配置放哪一层：local 、 project 、 user 三种作用域。