身份验证与授权

MCP-first 系统需要精确的安全架构。并非每个客户端都能看到每个工具。 并非每个智能体都能调用每个工具。并非每个操作都可以自主执行。 并非每条信息都可以进入 AI 上下文。

为此，必须清晰区分不同的身份类型，并为每种类型定义适当的 身份验证机制。

五种身份

人类用户（Human User）

系统的真实用户——拥有个人身份和基于角色的权限。 典型类型：管理员、员工、客户、项目经理、 支持人员、高管。

人类用户是基础身份。所有委托上下文最终都指向他。

MCP 客户端（MCP Client）

与 MCP 服务器连接的应用程序。MCP 客户端不是用户， 而是具有自身信任级别的技术主体。

示例：Claude Desktop、内部 AI 应用、自有移动应用、自有智能体 Worker、 外部集成客户端。

客户端只能看到符合其信任级别和已配置 Scope 的工具。

智能体身份（Agent Identity）

执行操作的具体智能体或 Workflow。智能体与运行它的客户端并不相同—— 它拥有独立的、有描述的身份，具有受限的能力。

示例：销售助理、薪资助理、支持智能体、DevOps 智能体、 报告智能体、个人助理。

委托用户上下文（Delegated User Context）

委托用户上下文确保智能体拥有的权限恰好等于其代表的用户所拥有的权限。 高管可以查看薪资数据——但在其上下文中运行的销售助理智能体 仍然不能将这些数据纳入其上下文。

服务身份（Service Identity）

用于没有直接用户上下文的后端到后端流程。服务身份是 具有固定且受限 Scope 的技术主体。

示例：导入 Worker、定时任务、同步 Worker、监控智能体、计费 Worker。

人类用户的身份验证

人类用户通过成熟的方式进行身份验证。选择哪种方式取决于 安全需求和使用场景：

• 邮箱 + 密码 — 基础访问，始终与双因素认证结合使用
• Passkeys — 抗网络钓鱼的密码替代方案，优先采用
• TOTP / 双因素认证 — 所有敏感区域的第二因素
• SSO — 用于具有中央身份管理的企业环境
• OAuth / OpenID Connect — 用于第三方登录和委托访问

MCP 客户端的身份验证

MCP 客户端通过带授权码流程和 PKCE 的 OAuth 2.1 进行身份验证。 这可防止代码注入攻击，适用于公共客户端（无安全客户端密钥）。

其他要求：

• 短期 Access Token — 最小化 Token 泄露时的损害
• Refresh Token 轮换 — 每次兑换 Refresh Token 都会生成新令牌； 旧令牌立即失效
• 客户端白名单 — 对于敏感系统，仅允许明确注册的客户端； 动态客户端注册受限或禁用
• 重定向 URI 验证 — 仅接受预先注册的 URI； 开放重定向是常见的攻击向量
• Token 绑定 — 在技术条件允许时，将 Token 与客户端绑定

内部服务的身份验证

后端到后端通信的要求与用户或客户端身份验证不同。 这里采用无交互身份验证步骤的技术机制：

• mTLS — 双向 TLS 身份验证；双方均通过证书进行身份证明
• 签名服务 Token — 短期、经加密签名的 Token，具有严格定义的 Scope； 不使用长期共享密钥
• 密钥管理器 — 凭据、证书和密钥从不存储在配置文件中， 而是通过中央密钥管理器进行管理和轮换
• 私有网络区 — 内部服务在隔离网段中通信； 不直接暴露于公共网络
• IP 白名单 — 对于关键系统，访问额外限制在已知 IP 范围内
• Token 轮换 — 服务 Token 也具有短期有效期，并定期更新