MCP 安全实战：OAuth 2.1 认证与授权最佳实践

Model Context Protocol (MCP) 在当今的代理式 AI 生态系统中越来越重要，因为它标准化了 AI 代理如何访问工具、数据源和外部系统。随着代理从被动聊天机器人转变为能够规划和执行任务的自主参与者，MCP 提供了一个结构化、可互操作的接口层，支持工具调用、增强安全性、对外部系统的受控访问以及在异构环境中更一致的策略执行。

MCP 在 LLM 驱动的推理与现代代理架构中的真实系统执行之间形成了连接纽带。但由于 MCP 充当通往敏感企业数据的强大桥梁，依赖隐式信任或未经核实的连接已不再可行。

MCP 认证基础

现代 MCP 规范定义 MCP 服务器充当 OAuth 2.1 资源服务器，而 MCP 主机代表用户充当 OAuth 客户端。作为安全措施，MCP 服务器应对任何请求要求有效的 OAuth 访问令牌。遵循 OAuth 2.1 提供最新的安全保护。例如，授权码流程强制要求使用 PKCE（Proof Key for Code Exchange）。

保护 MCP 服务器需要强大的认证来处理用户登录和同意。然而，最佳授权策略在很大程度上取决于部署场景。

三种部署场景的认证策略

1. 开放 MCP 生态系统（CIMD 方法）

对于期望与各种第三方 AI 客户端集成的独立 MCP 服务器（且不存在预先建立的关系），MCP 规范正在转变。虽然协议最初依赖动态客户端注册（DCR），但 DCR 给服务器带来了管理无边界客户端数据库和信任自我声明元数据的沉重负担。

相反，社区正转向 Client ID Metadata Documents（CIMD，SEP-991）作为推荐的默认方法。使用 CIMD，客户端只需在 HTTPS URL 上托管静态 JSON 元数据文件。这提供了一种去中心化的方式，让服务器动态验证客户端身份并建立信任，无需预先协调。

2. 企业 Kubernetes/OpenShift 环境

在严格控制的容器化环境中，依赖单个客户端注册（无论是 DCR 还是 CIMD）通常不切实际且不必要。这些场景的最佳实践是将认证卸载到外部 OpenID Connect (OIDC) 提供商，并利用 OAuth 令牌交换。

这允许平台的入口或 API 网关集中验证用户，通过将初始令牌交换为授予 MCP 服务器范围访问后端资源的内部令牌来增强安全性。

3. 内部/服务到服务部署

对于不直接面向最终用户但充当内部企业代理后端实用程序的 MCP 服务器，可以完全替换传统的用户登录和同意流程。在这些封闭生态系统中，连接安全应专注于使用相互 TLS (mTLS) 或安全的机器到机器 (M2M) OAuth 客户端凭据。

授权服务器集成：Keycloak 示例

在 MCP 服务器中处理 OAuth 有两种方法：嵌入式或外部授权服务器。嵌入式意味着 MCP 服务器内部有自己的身份提供商 (IdP)，自己呈现登录选项并颁发令牌。这可行，但会显著增加复杂性——本质上是从头开始构建 OAuth 提供商。

企业环境中的首选方法是委托给外部 OAuth/OIDC 提供商。在此模型中，MCP 服务器依赖外部授权服务器（例如 Red Hat Keycloak）来处理认证和令牌颁发的繁重工作。MCP 服务器然后简单地充当 OAuth 依赖方，验证传入请求的令牌并执行范围和角色检查。

这种分离遵循最佳实践，允许重用强大的身份基础设施，如企业单点登录和多因素认证。

同意和范围控制

认证实现的设计应使用户明确同意 MCP 服务器可以执行的操作。OAuth 范围旨在是细粒度的。例如，如果 MCP 服务器暴露”sendEmail”工具和”readContacts”工具，应定义单独的范围（如 email.send 和 contacts.read）。仅当令牌授予相应范围时，才允许服务器执行操作。

这强制执行最小权限原则，如果访问令牌被盗或丢失，可限制影响。在初始连接时，用户应看到 IdP 提供的同意屏幕，列出代理请求的范围和工具，并且必须批准它。MCP 服务器还应在每个请求上实施范围检查。

避免”困惑的代理人”和冒充攻击

基于 OAuth 的 MCP 流程中的主要风险是”困惑的代理人”问题。例如，如果 MCP 服务器使用单个静态 OAuth 客户端 ID 访问第三方 API，并且不正确地转发用户认证流程，攻击者可能欺骗它获取并非打算给它的令牌。

作为 MCP 服务器开发者，应遵循官方 MCP 授权规范指南，防止令牌重定向攻击，确保用户同意始终与正确的请求客户端绑定。使用 state 参数和重定向 URI 验证来挫败劫持。此外，考虑受众限制：服务器接受的令牌应包含服务器或资源的标识符，因此不能在其他地方重放。

集成基于角色的访问控制 (RBAC)

除了 OAuth 范围，企业部署通常需要更细粒度的授权。将 OAuth 令牌映射到内部角色和权限是很好的做法。例如，令牌可能在其声明中传达用户的角色。如果使用 Keycloak，可以在 JSON Web 令牌 (JWT) 中包含领域或客户端角色。然后 MCP 服务器可以仅允许具有管理员角色的用户使用某些敏感工具。

这增加了纵深防御，这是 Red Hat 安全原则的核心要素。在工具执行之前，在中间件中实施令牌声明检查。

安全令牌处理

将访问令牌和刷新令牌视为机密。仅根据需要将其存储在服务器端，并使用强加密。确保客户端和服务器实施 OAuth 2.1 第 7.1 节中的安全令牌存储指南。

如果 MCP 服务器需要使用用户令牌执行后续 API 调用，应避免长期令牌。使用短过期时间，如果用户会话较长且安全刷新流程正确，则利用刷新令牌。

切勿记录令牌或将其暴露给客户端用户界面 (UI) 或大型语言模型 (LLM)。应遵守失效和撤销——如果用户通过 IdP 撤销访问，MCP 服务器应使用 JWT 内省或通过尝试使用令牌并处理来自下游的 401 来检测令牌撤销。对于高安全场景，考虑使用发送方约束令牌（如 mTLS 或 DPoP），这样被盗令牌没有客户端密钥就无用。

总结

通过与强大的身份提供商集成并遵循 OAuth 2.1 流程，可以为 MCP 服务器建立强大的认证和授权基础。采用 OAuth 2.1 等现代标准、使用 Keycloak 等外部身份提供商以及通过范围执行严格的细粒度访问，有助于在代理式 AI 生态系统日益复杂的威胁环境中建立基本的防御层。

YUANLEISVIP

收藏 链接