MCP企业级认证的“无人区”：异构Auth、身份委托与用户/非用户角色问题的网关架构

2301_80078096

524人浏览 · 2026-08-16 20:33:48

2301_80078096 · 2026-08-16 20:33:48 发布

MCP企业级认证的“无人区”：异构Auth、身份委托与用户/非用户角色问题的网关架构

MCP在短短一年内从实验室走进生产环境，大型企业从零到数十个内部MCP Server的爆发式增长，同时制造了一场治理危机：每个团队独立实现认证——有的无认证，有的用API Key，有的跑完整OAuth——形成割裂的认证版图，没有统一授权方式，无法追踪谁做了什么，也无法在全网范围内清退离职员工。

一、认证困境的“三体问题”

1.1 异构Auth：各搞一套的必然结局

MCP协议的灵活性是双刃剑。规范明确定义了工具调用格式，但没有规定企业该如何保护这些调用。结果就是每个团队根据自己理解的“安全”各自实现：

认证方式	常见场景	问题
无认证	内部开发测试环境	任何人都能调用，审计空白
静态API Key	快速原型	无法细粒度授权，泄露即失守
OAuth 2.0	正式服务	实现复杂，不同服务间无法互通

1.2 身份委托：谁在代表谁？

当Agent代表用户执行操作时，身份委托成为核心挑战。一个典型场景：用户通过Claude Code调用MCP Gateway，Gateway再路由到下游MCP Server。中间的委托链条涉及三个独立的身份域——用户身份、Agent客户端身份、Gateway身份。

当前身份标准各有分工：OIDC证明终端用户身份，OAuth 2.0 Token Exchange建模委托访问，SPIFFE证明工作负载身份，MCP保障工具-服务器授权。但没有一个标准能覆盖完整的委托链。

1.3 用户/非用户角色：人的问题还是机器的问题？

MCP客户端的两种形态——交互式用户和自动化非用户——需要不同的信任模型。用户通过OIDC登录持有身份令牌；自动化Agent（CI/CD流水线、定时任务）持有服务账号凭证。现有规范无法统一处理这两种身份形态，当自动化Agent代表用户行动时，归因断裂：日志只记录“哪个自动化账号调用了工具”，无法追溯到最初触发该动作的“人”。

二、网关架构：MCP认证的“无人区”解决方案

2.1 网关的五个核心职责

2026年8月arXiv论文《A Gateway Architecture for Enterprise MCP Authentication》提出由中央MCP网关统一管理认证和治理，涵盖五个职责：

1. Auth：OAuth 2.1识别开发者，映射到用户角色；2. RBAC：按用户策略控制哪些服务器、工具、范围可访问；3. Audit：记录每次调用的谁、什么、何时、结果；4. Rate limit：按用户/工具/服务器设置上限；5. Policy：拒绝被投毒的工具描述、执行最小权限原则、脱敏PII。

一个网关汇聚所有下游MCP Server，对开发者看起来就像一个MCP端点，内部路由到N个后端。

2.2 双轴认证模型

arXiv论文提出的双轴认证模型：

角色轴：

Interactive User：人类用户登录，OIDC提供身份
Non-User：自动化Agent/流水线，持有服务账号凭证

凭证轴：无认证、静态API Key、动态API Key、PKCE、Client Credentials、平台应用上下文

网关将所有组合统一为一致的授权决策。

2.3 三种端到端身份流

User-to-OAuth2：用户经IdP认证，网关将ID Token兑换为下游服务器的访问令牌。

Non-user-to-Service-Account：自动化Agent持有服务账号密钥访问网关，网关依据预设策略映射到对应角色。

User-to-Service-Account：用户身份被“投影”到服务账号上下文，由网关完成身份映射和令牌交换，下游服务器看到的是代表该用户的标准化令牌。

三、核心实现：网关如何落地

3.1 ID-JAG与Token Exchange模式

IETF正在推进ID-JAG草案，定义了一种身份断言授权授予类型。网关作为可信代理：

客户端调用经网关传递OIDC ID Token
网关本地验证Token（签名、发行者、受众、过期时间），无每次请求回IdP验证
网关在IdP的Token Endpoint将ID Token兑换为ID-JAG，并提交给MCP Server的授权服务器换取作用域访问令牌
网关将请求代理到上游，携带该令牌

Kong AI Gateway已落地这一模式，网关一侧对不支持的客户端生成ID-JAG，另一侧在不支持的服务器前执行EMA决策。

3.2 凭证保管与中介模式

开发者永远看不到后端令牌，网关持有所有后端凭证（或代理至身份提供商）。开发者分配到notes:read范围，可访问笔记MCP Server，但权限受策略约束，且绑定归因链。

托管对象存储（MinIO、S3）的mcp-gateway实现作为聚合网关，提供认证（OAuth 2.0 + JWT）、路由、审计日志和速率限制，对开发者呈现为单一MCP Server端点。

3.3 网关认证代码示例

基于Kong AI Gateway的ID-JAG Relay插件配置：

plugins:
  - name: id-jag-relay
    config:
      audience: https://mcp.example.com
      id_token_audiences: ["my-client-app"]
      trusted_idps:
        - issuer: https://idp.example.com
          client_id: kong-broker
          client_secret: "{vault://env/kong-broker-secret}"

配置后网关作为ID-JAG能力客户端为无法实现的客户端代理，并将EMA决策执行在前端不支持的服务器前，让标准与现实相遇。

3.4 工具哈希锁定：防投毒

网关维护批准工具描述的清单（SHA256哈希），发现时获取每个后端的tools/list，将哈希与清单对比，移除描述变异的任何工具，从网关层统一防御描述篡改。

四、治理架构

4.1 个人级与租户级网关

Airia提出的两种网关模型：

属性	个人级网关	租户级网关
谁可见	仅创建者	组织内所有人
谁可编辑	仅创建者	平台管理员/安全管理员
适用场景	测试新服务器、个人工作流	团队共享工具集、公司级集成

4.2 成员模型：用户、机器人与API Key

Aptible MCP Gateway支持三种身份类型：

User：拥有Aptible账户的个人
Robot：用于流水线和Agent的非人类账户
API Key：绑定用户账户的作用域令牌

所有三类以相同方式添加到授权，受相同访问规则约束。

五、生产部署路径

5.1 技术成熟度现状

各厂商已推出MCP网关：Kong AI Gateway提供ID-JAG Relay、Cloudflare MCP Portals、IBM ContextForge、MintMCP、TrueFoundry、Envoy AI Gateway均在2025-2026年发布网关或网关功能。开源项目mcp-gateway提供认证、路由、命名空间与可观测性支持。

5.2 演进路径# MCP企业级认证的“无人区”：异构Auth、身份委托与用户/非用户角色问题的网关架构