MCP 工具开始接入 OAuth 后，最常见的错误不是“没有登录”，而是把不同角色混成一个概念：谁是客户端、谁是资源服务器、令牌到底发给谁、AI 中转站是否只是转发者。若拿到一个能用的 bearer token 就原样转给所有工具，后续很难收回权限，也无法证明请求只访问了被授权的资源。
先把四个对象写进接入图
客户端代表用户发起授权；授权服务器签发令牌；资源服务器验证令牌并保护工具或数据；中转站负责会话关联、策略判断和安全转发。中转站即使能看见令牌，也不应默认成为令牌的受众。每条工具连接都要记录资源标识、所需 scope、过期时间、授权主体和撤销入口。
测试令牌“能用但不该用”的场景
准备至少五组负面用例：错误 audience、缺少 scope、过期令牌、从另一租户复制的令牌、重定向到同域不同路径的资源。正确结果不是统一返回 500，而是资源端拒绝、审计可定位，并且中转站不在日志中保存原始 bearer 值。若工具需要代表用户访问第三方 API，优先使用短时、面向具体资源的令牌，而不是长期万能密钥。
中转站的代传策略
代传时应建立“调用者—工具—资源—授权记录”的绑定。工具声明变化、scope 扩张或资源 URL 改变时，要求重新确认。不要根据工具名称猜测权限，更不能把一个高权限连接自动复用到同名测试环境。对于后台任务，还要规定令牌过期后的行为：停止、提示重新授权，或使用明确审批过的服务身份。
上线检查表
- 能从可信元数据发现授权与资源端点，并校验 issuer；
- audience 与实际资源严格匹配，拒绝模糊前缀比较；
- scope 按读、写、删除和管理动作拆分；
- 授权撤销后，新请求立即失效，缓存连接不得继续使用；
- 审计记录令牌指纹、主体和范围，不记录完整令牌。
把不同 MCP 服务纳入 top-api.cc 的统一入口时，可将授权上下文与模型请求分开保存，方便查看每次工具调用究竟代表谁、访问了什么。这个边界能减少“模型换了，权限却还在”的隐蔽问题。
复盘时别只看授权成功率
还要统计 audience 拒绝、scope 不足、撤销生效延迟和重复授权率。授权成功率很高并不表示配置正确；如果所有请求都靠一个宽泛令牌通过，反而说明最小权限没有落地。用小范围灰度和可撤销连接先验证，再扩大到生产工具。
Leave a Reply