在标准的 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。MCP 资源服务器MCP 授权服务器企业 IdPMCP 客户端浏览器MCP 资源服务器MCP 授权服务器企业 IdPMCP 客户端浏览器用户登录用户已登录客户端客户端存储 ID 令牌评估策略校验 ID-JAGloop[循环调用]重定向到 IdP重定向到 IdPIdP 授权码IdP 授权码使用授权码发起令牌请求ID 令牌用 ID 令牌换取 ID-JAG返回 ID-JAG使用 ID-JAG 发起令牌请求MCP 访问令牌携带访问令牌调用 MCP API返回带数据的响应流程的四个关键点集中式策略企业 IdP 维护一份已批准的 MCP 服务器注册表和各自的访问策略管理员在现有身份管理工具里配置。单点登录SSO员工用企业凭证认证一次IdP 颁发的令牌即可访问已批准的服务器无需每个服务器额外弹授权提示。策略强制执行IdP 在签发令牌前会评估策略组成员身份、角色分配、条件访问规则。未获授权者收到相应错误——客户端永远拿不到未授权服务器的令牌。集中式撤销在 IdP 层面撤销即在所有客户端生效无需逐客户端、逐服务器操作。四、和 OAuth 2 是什么关系一句话它本身就构建在 OAuth 2 之上而不是取代它。MCP 的核心授权规范基于 OAuth 2.1OAuth 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。五、两种流程对比维度 标准 OAuth 2.1 企业托管授权授权决策者 用户本人 企业 IdPIT / 安全团队授权粒度 每个用户逐个服务器授权 集中策略一处配置全局生效关键令牌 授权码 → 访问令牌 ID 令牌 → ID-JAG → 访问令牌是否重定向到 MCP 授权端点 是 否改由 IdP 签发 ID-JAG撤销方式 逐客户端、逐服务器撤销 IdP 层面撤销立即全局生效底层协议 OAuth 2.1 授权码 PKCE 同为 OAuth 2扩展令牌交换RFC 8693最适场景 消费级应用、个人用户 企业环境、合规审计、SSO标准流程用户登录并同意授权↓MCP 授权服务器颁发访问令牌↓客户端携带令牌调用 MCP API企业托管流程用户用企业 SSO 登录得到 ID 令牌↓IdP 评估策略签发 ID-JAG↓用 ID-JAG 向 MCP 授权服务器换令牌↓客户端携带令牌调用 MCP API六、落地实现要点对 MCP 客户端声明支持——在 initialize 请求中声明扩展{“capabilities”: {“extensions”: {“io.modelcontextprotocol/enterprise-managed-authorization”: {}}}}支持 SSO——用户用企业 IdP 认证保存登录期间颁发的身份断言OpenID ID 令牌或 SAML 断言备用。处理 ID-JAG——当服务器指示需要企业托管授权时用先前的身份断言向 IdP 授权端点请求 ID-JAG再换取访问令牌不要把用户重定向到 MCP 授权服务器的授权端点。支持组织级配置——允许管理员在组织级而非按用户配置 IdP 端点。遵守令牌作用域——IdP 令牌的 scope 限制可能不同于标准 MCP 授权需优雅处理 scope 错误。对 MCP 服务器声明扩展——在授权元数据中声明客户端必须走企业托管流程。与 IdP 管理 API 集成可选——发布服务器资源描述符便于管理员在 IdP 控制台配置策略。对 MCP 授权服务器校验 ID-JAG——根据 IdP 的 JWKS 端点验证 JWT 签名检查 audience、issuer、过期时间。将 IdP 声明映射为权限——ID-JAG 携带 scope 和 resource 声明据此判断员工身份和可访问范围。处理账户关联——ID-JAG 始终含 subject 声明可能还含 email 声明可用于账户关联。七、发展时间线2025-06-04SEP-990 作为提案创建目标是在 MCP 的 OAuth 流程中启用企业 IdP 策略控制。2025-11-25在这一版 MCP 规范中作为最早的一批授权扩展之一被正式引入。2026-06-18官方博客宣布该扩展达到 stable稳定 状态可用于生产环境。一句话结论若指正式稳定可用是 2026 年 6 月若指进规范是 2025 年 11 月。需注意各 MCP 客户端和 SDK 的落地进度不一具体某客户端是否已实现需查客户端支持矩阵。八、值得警惕的问题与风险以下多为设计层面的权衡与潜在风险而非已被证实的缺陷是否成问题很大程度取决于具体 IdP 实现、令牌生命周期策略和部署方式。IdP 成为集中的高价值攻击目标。 授权决策全部收敛到 IdP好处是集中管控代价是攻击面也集中——IdP 一旦被攻破或配置错误波及的是所有 MCP 服务器。集中撤销的另一面就是集中失陷。“立即撤销要打折扣。 下发给客户端的是 OAuth Bearer 访问令牌通常有独立有效期。除非配合很短的 TTL 加令牌内省introspection否则已签发的访问令牌在过期前仍可用——“immediate更多指不再签发新令牌”而非已有令牌立刻作废”。用户失去知情与控制。 标准 OAuth 的价值恰恰是用户能看到自己在授权什么。企业托管把这一步拿掉后员工可能不清楚某个 MCP 服务器能访问他哪些数据。对企业是效率提升对个人隐私透明度是倒退——这是有意的取舍但值得明确。账户关联偏脆弱。 规范用 subject、可能还用 email 声明做跨系统身份匹配。用 email 作为身份依据历来是隐患邮箱会变更、会被回收复用一旦匹配错就是错误授权。信任链与权限映射复杂。 MCP 授权服务器必须信任 IdP 签发的 ID-JAG校验 JWKS、issuer、audience这套联邦信任的建立与维护并不轻松而把粗粒度的组织策略组、角色映射到细粒度的 MCP 权限容易出现授权过宽。生态成熟度与碎片化。 ID-JAG / 令牌交换这条路子还比较新能签发 ID-JAG 的 IdP、能处理它的客户端都还不多早期主要是 Okta 的 Cross-App Access 在推。加上它是 opt-in、默认不开、各客户端支持程度不一短期落地会比较零散还可能造成对特定 IdP 厂商的绑定。
