企业 MCP 接入怎样验收：登录、令牌目标和业务对象权限分开检查

一个受保护的远程 MCP 场景至少有客户端、MCP 服务和授权服务器。客户端代表用户发出工具请求；授权服务器签发访问令牌；MCP 服务验证令牌，再把允许的请求交给业务能力。它们可能由同一平台提供，也可能分别维护，不能只登记一个“连接器负责人”。

先记录 MCP 服务的规范地址、部署方、传输方式、支持的协议版本、允许的工具以及下游业务系统。授权元数据指向哪里、谁能更改工具配置、谁能停用连接，都要有实际负责人。模型看到的是工具描述和必要结果，不需要读取登录秘密。

2026-07-28 版 MCP 授权规范描述的是 HTTP 传输的授权流程；规范将授权列为可选能力，并说明 STDIO 应从环境取得凭证，不照搬这套 HTTP 流程。本文以下演练选择受保护的 HTTP 服务，不能据此推断所有 MCP 工具都自带 OAuth 登录。

订单号、工具名和步骤是本站教学设计，不是 MCP 标准字段。第一次只验证读取，能减少外部副作用，也便于看清身份到底在哪一层丢失。写操作需要另外加入当前状态、业务批准、幂等和结果查询检查。

MCP 官方规范要求客户端在授权和令牌请求中明确目标资源，服务端验证令牌是否针对自身资源签发，并处理无效或过期令牌。给另一个系统使用的 token，不能因为字符串格式正确就被当前服务接受。

验证方式由授权体系决定。令牌可能是 JWT，也可能是不透明令牌；不能假定解码一段文本就完成验证。使用与授权服务匹配的验证机制，检查签发来源、目标、有效状态和所需范围。客户端取得登录结果后，还要遵循当前规范的授权响应验证要求。

访问令牌通过请求头发送，不放进 URL 查询串。客户端与服务端的日志、错误返回和截图也不能复制秘密值。排查时记录错误类别与关联标识，必要证据通过受控入口查看。

scope 表达连接允许的能力范围。请求只读任务时先取得必要范围；新增写能力需要按授权流程处理，不能把遇到拒绝作为自动申请所有权限的理由。

scope 设计可以很细，也可以只划分读写能力，实际以平台合同为准。无论采用哪种方式，系统都需要表达客户、部门或租户的对象边界。共享一个服务凭证也可以由企业统一管理，但必须保留可信的用户上下文和对象授权，不能用共享凭证抹去所有用户差别。

拒绝可以发生在 HTTP 层，也可以作为工具的结构化错误返回。业务越权即使收到 HTTP 200，也不能被解释为任务成功；错误内容不应泄露无权对象的名称或正文。

这张表记录的是期望行为，读者要填写自己的实际结果。权限撤销能否及时生效，与令牌期限、业务授权缓存和平台撤销机制有关。不要只做一次退出登录演示，就宣称所有旧授权都已立即失效。

官方授权规范用 401 处理需要授权、无效或过期令牌，用 403 表达权限或 scope 不足。客户端应区分这些情况：令牌失效按受支持方式重新授权或刷新，范围不足按必要能力确认，业务对象拒绝则核对对象与岗位，不能全部提示“重新登录”。

自动刷新也有条件。授权服务未必签发刷新令牌，不能把它作为每种连接的默认能力。刷新凭证同样受保护；刷新失败后停止受影响调用，保留用户能理解的下一步。

如果连接已建立但工具参数不兼容，检查客户端、服务版本和工具合同。反复扩大登录权限不能修复 schema 改动。上线说明应把连接故障、身份故障和业务拒绝分别指向能处理的人。

交付包记录服务与授权地址、版本、凭证保管位置、用户映射、允许工具、业务边界、测试结果及停用方式。只写凭证位置和更新方法，不复制 token。由接管人员完成一次只读查询和一次受控拒绝，确认不是依赖原工程师的个人账号。

适用范围是企业接入业务工具的准备与验收。本文不代替完整 OAuth 实现，也不保证第三方客户端支持当前规范所有能力。选定客户端和服务后，按双方实际版本核对注册、发现、响应校验及传输要求，再开展隔离测试。