MCP 企业托管授权(EMA)
与 Agent 身份认证

Agent 进企业绕不开的一问:它代表谁行动、权限从哪来、公司怎么统一收放?EMA 扩展 2026 年 6 月转正 stable,本周 Anthropic / Microsoft / Okta 等落地——这份文档把「一次登录、全部继承」背后的整套身份机制讲透。

MCP 扩展OAuth / OIDC企业安全调研日期 2026-07-16

⚡ 开篇速览:30 秒版本

MCP 原本的授权模型是「每个员工、对每个 MCP 服务器、各自点一遍 OAuth 授权弹窗」。个人用户连自己的工具没问题,但放进公司就是灾难:入职要手动连十几个服务器、安全团队管不住谁连了什么、个人账号和工作账号混在一起。

企业托管授权(Enterprise-Managed Authorization,EMA)是 MCP 官方给出的答案:把「谁能连哪个服务器」这个决定,从每个员工手里收回来,交给公司已有的身份提供商(IdP,就是你公司统一登录用的那套系统,如 Okta)。管理员在 IdP 里配一次策略,员工用公司账号登录一次,被批准的 MCP 服务器就全部自动连上——没有授权弹窗,没有逐个配置。

标准 MCP 授权 企业托管授权(EMA) 员工 OAuth 弹窗① OAuth 弹窗② OAuth 弹窗③… 每人 × 每服务器都要点一遍 安全团队无法集中管控 员工 公司 IdP(如 Okta) 一次 SSO 登录,策略集中在这里 服务器 A ✓ 服务器 B ✓ 服务器 C ✓ 登录一次,批准过的服务器自动全部连上
左:老模型,每人对每个服务器逐一授权;右:EMA,授权决定收进公司 IdP,员工零操作继承。(依据 MCP 官方博客的对比图重绘)
🎯 一句话记住 EMA 的边界

EMA 回答的是「这个用户能不能把这个客户端连到这个服务器、拿哪些权限范围」;它永远不回答「这个具体动作、此刻、对这个资源,该不该执行」。连接层它管,动作层留给你自己建(第五节详讲)。

🧭 背景与动机

之前的世界:授权税拖垮企业采用

MCP 在企业里的扩散是自下而上的——员工一个连接器一个连接器地装,授权是事后才被认真对待的问题。MCP 官方在 EMA 发布公告里直说:「连接的 MCP 服务器带来的授权与反复弹出的同意提示,是企业环境里管理连接性的最大痛点之一。」具体是三个问题:

结果就是官方说的「授权税」:数据和工具明明都在,但大多数处于「没连上」的关闭状态,或者各家发明自己的脆弱变通方案。

发展脉络

2025-11-25 规范 MCP 服务器成为 OAuth 2.1 资源服务器 SEP-990 提案 社区起草 EMA, 进 ext-auth 扩展仓库 2026-06-18 转正 stable Okta / Anthropic / VS Code 及 7 家服务器首发支持 2026-07-28 新规范 授权体系整体加固, 扩展框架成为一等公民
EMA 时间线:从 2025-11 规范确立 OAuth 基础,到 2026-06-18 转正,再汇入 7 月 28 日的新版规范生态。

为什么这周又上了新闻?因为 InfoQ 等媒体在 7 月初集中报道了转正消息,且它正好卡在 MCP 2026-07-28 规范定稿前夕——那份「MCP 史上最大修订」把整个授权体系向 OAuth 2.1 / OpenID Connect 对齐,EMA 是这个大方向里最面向企业的一块。

🧩 核心概念与角色

先把四个角色分清(两个名字很像,别混)

MCP 客户端 Claude / VS Code / 你的 agent IdP 授权服务器 公司身份系统(Okta),发中间凭证 资源授权服务器 为 MCP 服务器发访问令牌 MCP 服务器 真正提供工具的一方 ① SSO 登录 + 换中间凭证 ② 拿凭证换访问令牌 ③ 带令牌调工具
四个角色:两个「授权服务器」干的是不同的活——IdP 按公司策略放行「人」,资源授权服务器验证凭证后发「进门的令牌」。

关键区分:IdP 授权服务器(公司身份系统)负责按组织策略判断「这个人可不可以」,发一张中间凭证后就退场;资源授权服务器(MCP 服务器那边的发令牌方)验证这张凭证,发出真正用于调用的访问令牌。IdP 从头到尾不在工具调用的路径上——这一点决定了 EMA 的能力边界。

术语表

IdP(Identity Provider,身份提供商)
公司统一管理员工账号和登录的系统,如 Okta、Microsoft Entra。你每天上班「单点登录」用的就是它。
SSO(Single Sign-On,单点登录)
登录一次公司账号,各个内部系统都认。EMA 就是把 MCP 服务器也挂进这个「都认」的范围。
ID-JAG(Identity Assertion JWT Authorization Grant)
EMA 的核心新事物:IdP 在验证你的 SSO 身份、跑完公司策略后,签发的一张短命(约 5 分钟)的 JWT 凭证,只能对指定的一个服务器兑换一次访问令牌,用完即弃。基于 IETF 的 oauth-identity-assertion-authz-grant 草案。
令牌交换(Token Exchange,RFC 8693)
OAuth 的标准玩法:拿一种令牌(你的 SSO 身份令牌)去换另一种令牌(ID-JAG)。EMA 的「公司策略在此刻生效」就发生在这次交换里。
JWT Bearer 授权(RFC 7523)
另一个 OAuth 标准:客户端把一张 JWT 当作「授权依据」直接提交给授权服务器换访问令牌。ID-JAG 就是走这条路兑换的。
受保护资源元数据(PRM,RFC 9728)
MCP 服务器公开的一份「说明书」,告诉客户端「给我发令牌的授权服务器在哪」。EMA 的发现机制复用它。
XAA(Cross App Access,跨应用访问)
Okta 提出的跨应用授权协议,EMA 实质上是把它标准化进 MCP 扩展。Okta 是首个支持 EMA 的 IdP。
扩展(Extension)
MCP 的官方插件机制:反向域名命名(EMA 的 ID 是 io.modelcontextprotocol/enterprise-managed-authorization),独立仓库、独立版本,客户端和服务器双方声明才启用。
🏢 类比:办公楼门禁

老模型像一栋楼里每间办公室都装自己的门锁,新员工要挨个房间找管理员配钥匙。EMA 像公司前台(IdP)发一张工卡:HR 在系统里定好「工程部能进 3 楼机房和 5 楼实验室」,员工入职刷卡即通,离职一键注销全部权限。但注意——工卡只决定你能进哪些门,进门之后你在房间里做什么,门禁系统看不见(这就是 EMA 的边界)。

⚙️ 工作原理:完整流程

整个 EMA 流程是三个 OAuth 标准件的叠加:一次 OIDC/SAML 登录 + 一次 RFC 8693 令牌交换 + 一次 RFC 7523 JWT Bearer 兑换。没有发明新的密码学,全是被验证过的标准积木。

MCP 客户端 公司 IdP 资源授权服务器 MCP 服务器 ① SSO 登录(OIDC/SAML,MFA 在此生效) ② 返回身份断言(ID Token) ③ 令牌交换(RFC 8693) ④ 签发 ID-JAG(公司策略在这一刻裁决!) ⑤ 提交 ID-JAG(RFC 7523 JWT Bearer) ⑥ 返回访问令牌(仅对这一个服务器有效) ⑦ 带 Bearer 令牌调用工具(循环进行) 注意:⑦ 之后 IdP 和资源授权服务器都已退场, 真正的工具调用循环里没有任何策略方在看着(→ 第五节)
EMA 端到端时序:公司策略只在第④步(签发 ID-JAG)那一刻运行;之后的工具调用循环,IdP 完全不可见。

逐步拆解

SSO 登录,拿到身份断言。客户端对 IdP 跑一次普通的 OIDC(或 SAML)登录。公司设置的 MFA、条件访问在这一步照常生效。客户端拿到并保存一张身份断言(OIDC 的 ID Token;SAML 要先多换一步 refresh token)。
令牌交换,换取 ID-JAG。客户端向 IdP 的 token 端点发起 RFC 8693 交换:带上身份断言、目标资源授权服务器(audience,必填)、目标 MCP 服务器标识(resource,可选)和想要的 scope。这是全流程中公司策略唯一运行的时刻——IdP 依据组、角色、条件访问规则裁决。被拒绝的服务器什么也不返回,对客户端来说等于「不存在」。
兑换访问令牌。客户端把 ID-JAG 作为 RFC 7523 JWT Bearer 授权提交给资源授权服务器。后者验证签名、签发方、受众等,发回一张普通的 OAuth 访问令牌——且必须受众绑定到 ID-JAG 里指定的那一个 MCP 服务器,拿去调别的服务器无效。
正常调用与静默续期。之后就是普通 MCP:每次调用带 Bearer 令牌;令牌过期时用保存的身份断言静默重跑交换,无需用户再操作;只有身份断言本身过期才回到 SSO 登录。全程用户没见过任何一个授权弹窗。

ID-JAG 里面装了什么

它就是一张带特殊类型标记(typ: oauth-id-jag+jwt)的 JWT,关键字段(示例取自 Ehsan Hosseini 的规范解读文章):

{
  "iss": "https://acme.idp.example",     // 谁签的(公司 IdP)
  "sub": "U019488227",                   // 用户(仅在 iss 内唯一,必须 iss+sub 连用)
  "aud": "https://auth.chat.example/",   // 给谁用(资源授权服务器)
  "resource": "https://mcp.chat.example/", // 最终目标(那一个 MCP 服务器)
  "client_id": "f53f191f9311af35",
  "scope": "chat.read chat.history",     // 权限上限(只能收窄,不能放大)
  "exp": ..., "iat": ..., "jti": "..."   // 约 5 分钟过期 + 防重放 ID
}

三个设计值得品味:短命(约 5 分钟,兑完即弃,偷走也几乎没用)、单一目标(一张凭证只对一个服务器,没有「万能票」)、scope 是天花板(资源授权服务器只能发等于或小于凭证 scope 的令牌)。

客户端怎么发现服务器支持 EMA

两步查询,没有任何自定义端点:先通过服务器的受保护资源元数据(RFC 9728)找到它的资源授权服务器;再看该授权服务器的元数据里 authorization_grant_profiles_supported 数组是否包含 urn:ietf:params:oauth:grant-profile:id-jag。客户端自己则在能力声明的 extensions 映射里报出 EMA 的扩展 ID。扩展是双向可选的,任一方没声明就回落到标准授权流程。

⚠️ 时效提醒:能力声明的载体正在变

EMA stable 规范写作时,扩展声明放在 initialize 握手的 capabilities 里;而 2026-07-28 新规范取消了 initialize 握手,能力改为随每个请求的 _meta 传递、用 server/discover 按需获取。具体声明位置以官方 ext-auth 仓库的最新版本为准。

🛠️ 怎么用:三方各自的实现要点

EMA 涉及三个建设方。以下要点整理自官方扩展规范页与 Ehsan Hosseini 的实现清单(他的文章是目前对请求细节还原最完整的第三方解读)。

如果你是企业管理员(只想用,不写代码)

如果你在实现 MCP 客户端

如果你在实现资源授权服务器(MCP 服务器一侧)

🚧 边界:EMA 管到哪为止,剩下的归谁

这是全文最重要的一节,也是最容易被误读的一点。把「IdP 批准了这个连接」读成「这个连接是安全的」,是对规范的误读——规范自己在安全考量里写明:IdP 的可见性止于签发令牌的那一刻,不延伸到之后客户端与服务器之间的 MCP 流量。

连接层 —— EMA 管这里 ✓ 谁(iss+sub)· 用哪个客户端 · 连哪个服务器 · 拿哪些 scope 决定时机:签发令牌那一刻,一次性 动作层 —— EMA 不管,留给你 ✗ 这一次调用 · 此刻 · 对这个资源 · 出于这个目的,该不该放行? 需要自建:策略决策点(PDP)+ 数据路径上的策略执行点(PEP)
EMA 的结构性边界:连接层的「能不能连」它管;动作层的「该不该做」在协议上就不可能由它管——IdP 不在调用路径上。

一个具体的例子

一个发布 agent 通过 EMA 连上了代码仓库服务器,且合法地持有写权限 scope(它确实有时需要写)。EMA 给它发了一张有效令牌——然后就没有然后了。任务执行中途,没有任何 EMA 机制阻止它删掉一个不该删的分支,或对任务范围之外的仓库动手。令牌说的是「这个用户可以在这里写」,对「这个动作、此刻、为了这个目的」一言不发。

补齐缺口:PDP / PEP 策略层

要管住动作层,必须在数据路径上放东西:一个夹在客户端与服务器之间的执行点(PEP),每次调用都过它,它向独立的决策引擎(PDP,可用 OPA、Cedar、OpenFGA 这类策略引擎)询问「放行 / 拒绝 / 要求升级验证」,并可附带义务(遮蔽字段、要求人工批准、提级记录)。决策与执行分离,策略可以独立演进,每个决定都成为可签名的审计事件。Hosseini 文中给了一个 Rego 规则示意(如「工程组可在本组仓库读写但不可删除」「agent 发起的删除一律要人工批准」)。

💬 社区声音

Okta 身份标准总监 Aaron Parecki(EMA 所基于的 XAA 协议作者):「随着我们走向互联的 AI 工作力,安全不能是事后补丁。把 Cross App Access 协议嵌入 MCP 成为 EMA 扩展,我们把身份变成集中治理平面。」同时 SecurityWeek 等安全媒体提醒:授权集中化本身也改变了攻击面——IdP 成为更高价值的单点目标,agent 权限聚合后一次失陷的爆炸半径更大。两种声音都值得听。

🌍 生态与落地现状(截至 2026-07-16)

1
正式支持的 IdP
(Okta,经 XAA)
2+
客户端阵营:Anthropic 全家桶
+ VS Code(预览)
7
首发支持的服务器:Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase
≈5 分钟
ID-JAG 有效期
(短命、单目标、一次性)

⚖️ 对比与选型

维度标准 MCP OAuth(逐服务器)EMA(企业托管)静态 API Key / PAT
授权决定者每个用户自己公司 IdP 管理员拿到 key 的任何人
用户体验每服务器一次弹窗,过期重来一次 SSO,零弹窗手动粘贴配置
集中策略/审计无IdP 控制台统一无(且难以轮换)
离职回收逐服务器撤销IdP 一键,全局生效常被遗忘,长期风险
身份保证可能混入个人账号强制公司身份无身份概念
适用场景个人用户、消费级(仍是默认)企业部署应尽量淘汰
动作级控制三者都没有 —— 一律需要另建 PDP/PEP 策略层

怎么选

放进大图景:07-28 规范的授权加固

EMA 不是孤立事件。即将定稿的 MCP 2026-07-28 规范把整个授权底座向 OAuth 2.1 / OIDC 拉齐:MCP 服务器必须实现受保护资源元数据(RFC 9728)、客户端必须用资源指示符(RFC 8707)声明令牌目标(防止令牌被拿去打别的服务器)、客户端注册转向 CIMD(Client ID Metadata Documents,动态客户端注册 DCR 被弃用)、强制校验授权响应的 iss(防混淆攻击)、规范化 refresh token 行为。EMA 站在这些地基之上,负责「企业如何批量发放这一切」。

🕳️ 常见坑与限制

⚠️ 最容易踩的一个:MCP 令牌 ≠ REST API 令牌

EMA 流程发出的访问令牌受众限定于那一个 MCP 服务器。它不是该厂商通用 REST API 的凭证——那套 API 在自己的授权服务器、受众和 grant 后面,是平行的另一个集成,不是 EMA 的赠品。Hosseini 特别点名这是团队摔得最狠的地方。

🎯 学完检验:三个自测问题

① 为什么说「公司策略只在一个瞬间运行」?那个瞬间是流程里的哪一步?② 一张 ID-JAG 被中途窃取,攻击者能拿它做什么、不能做什么(提示:typ / aud / resource / exp / jti 各挡住了什么)?③ EMA 上线后,你的发布 agent 误删分支的风险变小了吗?为什么没有——要靠什么补?

📚 学习资源