一、一句话概括

企业托管授权是 MCP 的一个授权扩展，它把"用户是否可以访问某个 MCP 服务器"的决策权，从每个员工自己手里，集中收敛到组织的身份提供商（IdP）手里。员工用企业 SSO 登录一次，IdP 根据组织策略决定放行哪些 MCP 服务器，员工无需再对每个服务器逐一做 OAuth 授权。

它不是一套新协议，而是构建在 OAuth 2 之上的扩展。

二、为什么需要它

在标准的 MCP 部署里，每个用户各自独立地授权某个 MCP 客户端访问某个 MCP 服务器。对消费级应用来说，这种"用户驱动"的模式很理想——个人掌握自己数据的访问权。

但放到企业环境里，这套模式会暴露出摩擦和安全缺口：

• 员工不应当需要去理解组织用到的每一个 MCP 服务器的授权细节。
• 如果每个人都独立授权，安全团队就无法强制执行一致的访问策略。
• 新员工入职要手动授权几十项服务。
• 员工离职要在每项服务上逐一撤销访问。

企业托管授权通过引入组织 IdP 作为权威决策者来解决这些问题。IdP（如 Okta、Azure AD 或企业 SSO 系统）统一控制员工能访问哪些 MCP 服务器、在什么条件下访问。员工用企业身份认证——就是他们用于邮箱、Slack 等办公工具的同一套凭证——IdP 再依据组织策略授予或拒绝访问。

适用场景：在企业环境中部署 MCP、需要强制执行组织访问策略、希望集中式增删访问、需要可审计的授权记录、希望员工用现有企业 SSO 凭证直接访问 MCP 工具。

三、它是怎么工作的

该扩展建立了一种委托授权流程：企业 IdP 充当 MCP 客户端与 MCP 服务器之间的中介。

核心是一种特殊令牌——身份断言 JWT 授权授予（Identity Assertion JWT Authorization Grant，简称 ID-JAG）。流程分两步：MCP 客户端先向企业 IdP 换取 ID-JAG，再用 ID-JAG 向 MCP 服务器的授权服务器换取访问令牌（access token）。

sequenceDiagram participant UA as 浏览器 participant C as MCP 客户端 participant IdP as 企业 IdP participant MAS as MCP 授权服务器 participant MRS as MCP 资源服务器 C-->>UA: 重定向到 IdP UA->>IdP: 重定向到 IdP Note over IdP: 用户登录 IdP-->>UA: IdP 授权码 UA->>C: IdP 授权码 C->>IdP: 使用授权码发起令牌请求 IdP-->>C: ID 令牌 note over C: 用户已登录客户端<br/>客户端存储 ID 令牌 C->>IdP: 用 ID 令牌换取 ID-JAG note over IdP: 评估策略 IdP-->>C: 返回 ID-JAG C->>MAS: 使用 ID-JAG 发起令牌请求 note over MAS: 校验 ID-JAG MAS-->>C: MCP 访问令牌 loop 循环调用 C->>MRS: 携带访问令牌调用 MCP API MRS-->>C: 返回带数据的响应 end

流程的四个关键点：

1. 集中式策略：企业 IdP 维护一份已批准的 MCP 服务器注册表和各自的访问策略，管理员在现有身份管理工具里配置。
2. 单点登录（SSO）：员工用企业凭证认证一次，IdP 颁发的令牌即可访问已批准的服务器，无需每个服务器额外弹授权提示。
3. 策略强制执行：IdP 在签发令牌前会评估策略（组成员身份、角色分配、条件访问规则）。未获授权者收到相应错误——客户端永远拿不到未授权服务器的令牌。
4. 集中式撤销：在 IdP 层面撤销即在所有客户端生效，无需逐客户端、逐服务器操作。

四、和 OAuth 2 是什么关系

一句话：它本身就构建在 OAuth 2 之上，而不是取代它。

MCP 的核心授权规范基于 OAuth 2.1（OAuth 2.0 加上安全强化，例如强制 PKCE）。企业托管授权是在标准 OAuth 授权码流程之上的扩展，复用了 OAuth 的关键构件：

• 登录阶段仍走标准 OAuth 授权码流程（授权码 → 令牌请求 → ID 令牌）。
• 换取访问令牌的环节使用 OAuth 2 令牌交换（RFC 8693, Token Exchange） 机制，即用 ID-JAG 去换 access token。
• 最终调用 MCP API 时携带的仍是标准 OAuth Bearer 访问令牌。

因此 ID-JAG 是一种基于 JWT 的授权授予（grant type），属于 OAuth 2 授权授予体系里的一员，而非另起炉灶。

唯一的本质区别在于"由谁做授权决策"：标准流程里用户直接在 MCP 授权服务器授权；企业托管模式下，客户端不会把用户重定向到 MCP 授权服务器的授权端点，而是由企业 IdP 先做策略评估、签发 ID-JAG，再拿去换令牌。协议底座还是 OAuth 2，只是把决策权集中到了 IdP。

五、两种流程对比

标准流程

用户登录并同意授权
        ↓
MCP 授权服务器颁发访问令牌
        ↓
客户端携带令牌调用 MCP API

企业托管流程

用户用企业 SSO 登录，得到 ID 令牌
        ↓
IdP 评估策略，签发 ID-JAG
        ↓
用 ID-JAG 向 MCP 授权服务器换令牌
        ↓
客户端携带令牌调用 MCP API

六、落地实现要点

对 MCP 客户端

1. 声明支持——在 initialize 请求中声明扩展：

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/enterprise-managed-authorization": {}
    }
  }
}

2. 支持 SSO——用户用企业 IdP 认证，保存登录期间颁发的身份断言（OpenID ID 令牌或 SAML 断言）备用。
3. 处理 ID-JAG——当服务器指示需要企业托管授权时，用先前的身份断言向 IdP 授权端点请求 ID-JAG，再换取访问令牌；不要把用户重定向到 MCP 授权服务器的授权端点。
4. 支持组织级配置——允许管理员在组织级（而非按用户）配置 IdP 端点。
5. 遵守令牌作用域——IdP 令牌的 scope 限制可能不同于标准 MCP 授权，需优雅处理 scope 错误。

对 MCP 服务器

1. 声明扩展——在授权元数据中声明客户端必须走企业托管流程。
2. 与 IdP 管理 API 集成（可选）——发布服务器资源描述符，便于管理员在 IdP 控制台配置策略。

对 MCP 授权服务器

1. 校验 ID-JAG——根据 IdP 的 JWKS 端点验证 JWT 签名，检查 audience、issuer、过期时间。
2. 将 IdP 声明映射为权限——ID-JAG 携带 scope 和 resource 声明，据此判断员工身份和可访问范围。
3. 处理账户关联——ID-JAG 始终含 subject 声明，可能还含 email 声明，可用于账户关联。

七、发展时间线

• 2025-06-04：SEP-990 作为提案创建，目标是在 MCP 的 OAuth 流程中启用企业 IdP 策略控制。
• 2025-11-25：在这一版 MCP 规范中，作为最早的一批"授权扩展"之一被正式引入。
• 2026-06-18：官方博客宣布该扩展达到 stable（稳定） 状态，可用于生产环境。

一句话结论：若指"正式稳定可用"，是 2026 年 6 月；若指"进规范"，是 2025 年 11 月。需注意各 MCP 客户端和 SDK 的落地进度不一，具体某客户端是否已实现需查客户端支持矩阵。

八、值得警惕的问题与风险

以下多为设计层面的权衡与潜在风险，而非已被证实的缺陷；是否成问题，很大程度取决于具体 IdP 实现、令牌生命周期策略和部署方式。

1. IdP 成为集中的高价值攻击目标。 授权决策全部收敛到 IdP，好处是集中管控，代价是攻击面也集中——IdP 一旦被攻破或配置错误，波及的是所有 MCP 服务器。集中撤销的另一面，就是集中失陷。

2. "立即撤销"要打折扣。 下发给客户端的是 OAuth Bearer 访问令牌，通常有独立有效期。除非配合很短的 TTL 加令牌内省（introspection），否则已签发的访问令牌在过期前仍可用——"immediate"更多指"不再签发新令牌"，而非"已有令牌立刻作废"。

3. 用户失去知情与控制。 标准 OAuth 的价值恰恰是用户能看到自己在授权什么。企业托管把这一步拿掉后，员工可能不清楚某个 MCP 服务器能访问他哪些数据。对企业是效率提升，对个人隐私透明度是倒退——这是有意的取舍，但值得明确。

4. 账户关联偏脆弱。 规范用 subject、可能还用 email 声明做跨系统身份匹配。用 email 作为身份依据历来是隐患：邮箱会变更、会被回收复用，一旦匹配错就是错误授权。

5. 信任链与权限映射复杂。 MCP 授权服务器必须信任 IdP 签发的 ID-JAG（校验 JWKS、issuer、audience），这套联邦信任的建立与维护并不轻松；而把粗粒度的组织策略（组、角色）映射到细粒度的 MCP 权限，容易出现"授权过宽"。

6. 生态成熟度与碎片化。 ID-JAG / 令牌交换这条路子还比较新，能签发 ID-JAG 的 IdP、能处理它的客户端都还不多（早期主要是 Okta 的 Cross-App Access 在推）。加上它是 opt-in、默认不开、各客户端支持程度不一，短期落地会比较零散，还可能造成对特定 IdP 厂商的绑定。

九、总结

企业托管授权补上了 MCP 在企业场景下缺失的"集中授权"这一环：用 IdP 做决策者、用 ID-JAG 做中间令牌，在不脱离 OAuth 2 底座的前提下，把逐用户、逐服务器的授权变成一处配置、全局生效。它显著改善了企业的部署效率、策略一致性和可审计性。

但采用时应清醒对待代价：IdP 单点风险、撤销时效的实际边界、用户知情权的让渡、账户关联的脆弱性，以及当前生态的不成熟。建议在引入前，围绕令牌生命周期策略、IdP 选型与联邦信任配置、以及权限映射粒度，做一次专门的安全评审。

参考资料

• Enterprise-Managed Authorization — Model Context Protocol
• Enterprise-Managed Authorization: Zero-touch OAuth for MCP（MCP 官方博客）
• SEP-990 · Issue #990（modelcontextprotocol）
• AI Model Context Protocol Adds Centralised Auth for Enterprise（InfoQ）
• ext-auth 代码库