MCP Server 鉴权与 RBAC 设计：OAuth2、JWT、Scope 精细化授权

MCP（Model Context Protocol）在 2024-2025 年快速成为 Agent 工具调用的事实标准，但企业落地时几乎都会遇到同一个问题：MCP Server 怎么鉴权？本文系统讲解 MCP Server 的鉴权设计，从协议规范到企业级 RBAC 落地。

一、MCP 协议自带的认证机制

MCP 协议规范（2025-03-26 版本）定义了两类认证。

1.1 Bearer Token（HTTP 传输）

当 MCP Server 通过 HTTP/SSE 传输时，使用标准的 Bearer Token：请求头为 Authorization: Bearer 。Token 由 MCP Client 提供，Server 验证后允许调用。

1.2 OAuth2 Authorization Code Flow（公开 MCP Server）

对于公网 MCP Server，MCP 协议要求实现 OAuth2 流程：客户端请求授权 → 用户在授权服务器登录后回调到 MCP Server → 用 code 换取 access_token → 保存 token。这是协议规范要求的最小实现。

二、企业级 RBAC 的真实需求

公网 OAuth2 在企业内部远远不够。真实企业场景的需求：多团队隔离（财务团队的 MCP Server 不能被工程团队访问）、多资源隔离（同一个 MCP Server 里，文档 A 不能被用户 X 访问）、多操作粒度（用户可以 read 但不能 delete）、审计追溯（谁在什么时间调用了什么工具）、临时授权、SSO 集成。

这些需求需要三层权限模型：认证层（你是谁？OAuth2、SSO）、授权层（你能做什么？RBAC、ABAC）、审计层（你做了什么？日志、追溯）。

三、MCP Server 的 RBAC 架构

3.1 三级权限粒度

Level 1（工具级）：能不能调用某个工具？Level 2（资源级）：能不能访问某个资源？Level 3（操作级）：能 read 但能 write 吗？能 delete 吗？

3.2 完整调用流程

MCP Client 发起工具调用 → MCP Server 解析 JWT Token 提取 user_id, roles, scopes → Authentication Middleware 验证 Token 有效性 → Authorization Engine 查询 user 的 RBAC 配置 → Permission Resolver 匹配三层权限（工具级、资源级、操作级）→ Tool Implementation 执行实际工具调用 → Audit Logger 记录调用日志。

四、JWT + Scope 的实现

企业内部最常用的方案是 JWT Token + Scope。JWT Payload 包含 subject（user id）、name、email、iat、exp、aud、iss、scope（空格分隔的权限声明）、roles（用户角色）、teams（用户所属团队）、resource_acl（资源级 ACL）。

FastMCP + Keycloak 集成示例：配置认证提供者（jwks_uri、issuer、audience），在每个 tool 函数中：提取 JWT Token、工具级权限检查（scopes 包含 github:write）、资源级权限检查（resource_acl 允许）、审计日志（user、tool、resource、action）、调用 GitHub API。

五、Token Exchange：用户身份的传递

MCP Server 调用 GitHub API 时，应该用谁的 token？三种方案：

Bot Token（共享账号）：简单、审计清晰，但无法追溯到个人用户，rate limit 共享。
User Token Impersonation（用户 token）：操作追溯到个人用户，个人 rate limit，但需要用户 OAuth 授权，token 存储复杂。
OAuth2 Token Exchange（RFC 8693）：标准化、不需要单独存储 user token、Keycloak 自动管理生命周期，但需要 Keycloak 配置 GitHub Identity Provider。

企业级推荐 Token Exchange，这是 OAuth2 标准，企业身份服务（Keycloak、Auth0、Okta）都支持。

六、三大企业身份服务集成

6.1 Keycloak（开源，企业首选）

Keycloak 是最常见的开源企业身份服务。集成步骤：创建 Realm → 创建 MCP Client → 创建 Role → 配置 Scope → MCP Server 用 Keycloak JWKS 验证 token。优势是完全开源、支持 LDAP/Active Directory 联合认证、有完整管理后台。

6.2 Auth0（SaaS，开发者友好）

Auth0 是开发者最友好的 SaaS 身份服务，集成最简单，用 express-oauth2-jwt-bearer 中间件 5 行代码搞定。优势是 5 分钟集成、UI 漂亮、文档清晰，适合中小团队。

6.3 Ory Hydra（云原生）

Ory Hydra 是云原生 OAuth2/OIDC 服务器，特点是微服务架构、Kubernetes 原生。优势是 API 优先、Kubernetes 友好、与 Ory Kratos 无缝集成，适合云原生团队。

七、Scope 设计最佳实践

7.1 Scope 命名规范

格式为 :[:]。示例：github:read（读 GitHub 任何资源）、github:repo:company/api（写特定仓库）、docs:write:engineering（写工程团队文档）、files:write:own（写自己的文件）。

7.2 最小权限原则

scope 越宽泛越危险，应该按用户和场景精细化。mcp:admin 给了用户太多权限，一旦 token 泄露后果严重。

7.3 Scope 与 Role 的区别

Scope 是 Token 内嵌的权限声明，签发时确定；Role 是用户身份的属性，可动态调整。实习生入职 default_scopes 是 docs:read，工程师是 github:read + docs:read + files:write:own，技术负责人是全权限。

八、审计与可观测性

审计是 RBAC 系统的另一半，没有审计的 RBAC 是纸面权限。使用 OpenTelemetry + 结构化审计日志，每个工具调用记录：user_id、user_email、tool、resource、action、result、timestamp、trace_id、client_ip、user_agent。

九、常见陷阱

scope 越多越好：宽泛的 scope 是安全风险。
JWT 永不撤销：JWT 默认无撤销机制，需要短期 access token + refresh token + 黑名单。
Bot Token 可以共享：Bot Token 共享意味着无法追溯到个人。
权限检查放在前端：MCP Client 不应该信任，Server 必须独立验证。
资源级权限用 if-else 散落：权限逻辑必须集中管理。
审计日志只记成功：失败/拒绝的调用也要记录，攻击检测依赖失败日志。

十、推荐方案

场景	推荐
公网 MCP Server	OAuth2 Authorization Code Flow + PKCE
中小团队企业内	Keycloak + JWT + Scope
SaaS 优先团队	Auth0
云原生 / K8s 团队	Ory Hydra + Ory Kratos
超大规模	Keycloak + Policy Engine（OPA）
金融/政府高合规	Keycloak + Token Exchange + 全链路审计

十一、未来趋势

MCP 协议原生 Scope、Policy as Code（OPA、Cedar 集成）、AI-Aware RBAC（基于用户行为模式的动态权限）、跨 MCP Server 联邦（多个 MCP Server 之间的信任传递）。

最后一句话：MCP Server 的鉴权不是可选项，是企业落地的入场券。