AREX Feed Article
Claude 插件登录后自动连接进入 beta，Team 与 Enterprise 管理员可统一配置
11 月 3 日 18:09 UTC（北京时间 11 月 4 日 02:09），Anthropic 的开发者账号 ，Claude 用户现在可以在登录后自动连接插件，前提是 MCP（Model Context Protocol）服务器接受 Claude 作为可信发行方（trusted issuer）。同一组帖文还说明，Team 与 Enterprise 管理员可以通过身份提供方（IdP）为整个组织配置插件；如果身份提供方不支持企业托管授权（Enterprise-managed auth，EMA），Claude 可以直接为每位已登录成员作担保。
Anthropic 的 Boris Cherny（@bcherny），逐个登录公司插件很烦人，所以团队做了自动连接：管理员配置好后，成员登录后第一次使用插件时就已经连上。Anthropic 的写得更具体：连接器在用户第一次需要它时「已经连接好，没有登录页，也没有同意屏」。其中 Claude 作为可信发行方的自动连接目前是测试版（beta），适用范围是 Team 与 Enterprise 套餐。
管理员配一次，成员首次用到时已经连上
对成员来说，变化是：不用自己搜索插件、登录服务、逐个点授权；管理员在组织设置里配置一次，访问权限随角色继承。配置入口在 Claude 的 Organization settings > Connectors。管理员选中一个连接器，在 Configuration 标签页的 Managed authorization 旁点「Set up」，然后依次选择身份来源、角色和权限范围。身份来源有两种：IdP-managed 和 Claude-issued。角色可以是内置的 User、Admin、Owner、Primary owner，也可以是自定义角色；管理员可以只选某个团队的自定义角色，先做小范围试点，再扩展到全组织。权限范围（Scopes）决定 Claude 可以向连接器请求哪些权限，之后还可以在具体角色的 Connectors 标签页里进一步收窄。
Anthropic 在推文里说「插件自动连接」，帮助文档的配置对象则写成「连接器」。本身可以打包技能、连接器和子代理；这次自动连接落在插件所带的 MCP 连接器上。插件本身对所有付费套餐开放，但这次公告的托管自动连接 beta 只列了 Team 与 Enterprise。插件和连接器的叫法不同，成员第一次用到时，背后的连接已经就绪。
管理员还可以同时开启浏览器登录（Browser sign-in）和 Managed authorization。帮助文档写明，Claude 会先尝试托管授权；如果失败，再提示成员单独登录，避免身份提供方出问题时成员无法连接。管理员也能要求某个连接器只走托管授权，防止个人账号混进工作工具。如果成员的 Claude 邮箱和连接器里的账号邮箱对不上，自动连接不会发生，成员会看到通常的 Connect 提示。
两条身份路径：IdP 托管已是正式版，Claude 签发还在 beta
Anthropic 的帮助文档写明，EMA 里的 IdP-managed auth 已经正式可用（GA），Claude-issued auth 仍是 beta。11 月 3 日的把两者放在一起说，但这次进入 beta 的是后者：让 Claude 自己作为可信发行方，给连接器签发身份断言。
IdP-managed 路径依赖 Claude 与连接器之间的单点登录（SSO）：身份提供方把用户签进连接器，访问决策、权限范围和可访问数据由身份提供方的策略和连接器自己的权限决定。帮助文档目前点名支持 Okta，并称更多身份提供方即将支持。对已经在用 Okta 的组织，这是一条正式可用的路径；成员被身份提供方移除时，连接器访问也会同时被移除。
Claude-issued 路径不需要身份提供方或 SSO。Claude 会向连接器的授权服务器发送一条签名断言，发行方 URL 属于客户自己的 Claude 组织。Anthropic 的给出的格式是 https://identity.anthropic.com/issuers/<issuer-id>。连接器服务方要把这个 URL 加进可信发行方列表；之后 Claude 用一条短期 JWT（JSON Web Token）断言，向连接器的授权服务器换取访问令牌（access token）。整个交换遵循 MCP 的（io.modelcontextprotocol/enterprise-managed-authorization）和 ID-JAG（Identity Assertion JWT Authorization Grant，身份断言 JWT 授权许可）；Anthropic 称这项扩展是开放的。Claude 向授权服务器发 POST /token，带上 JWT bearer grant（JWT 持有者授权）和签名断言；授权服务器检查 iss、拉取密钥、验证签名，再校验 typ、aud、client_id、exp、jti，通过后返回访问令牌。Claude 随后用这个令牌调用 MCP 服务器。
Anthropic 开发者文档中的 EMA 令牌交换流程。图片：Anthropic
Claude 签发的断言有几个明确特征：它说明用户是所属 Claude 组织的当前成员，email 是用户 Claude 账号的地址（小写）；它不说明用户是否通过组织 SSO 登录、是否用了多因素认证，也不携带组信息。每条断言在一分钟内过期，每次登录和续期都会生成新的断言。访问令牌的有效期由连接器的授权服务器决定；令牌过期后，Claude 可以不再打扰用户，直接再取一条断言换新令牌。
Claude-issued 的定位在里被描述为「身份提供方不支持 EMA 时」的兜底；帮助文档则把它写成一条独立的身份来源，不需要 IdP 或 SSO，但仍然建议组织启用 SSO。两种说法可以并存：它既是兜底（fallback），也是一条可以单独配置的路径。
14 个插件进入 beta，完整 EMA 名单更大
列出的 Claude-issued beta 插件有 14 个：Amplitude、Apollo.io、Atlassian、Datadog、Dropbox、Figma、Granola、HubSpot、Linear、Mixpanel、Notion、PagerDuty、Semrush 和 Supabase。这个名单与帮助文档的 beta 名单一致。
帮助文档里支持 EMA 的完整连接器名单更长，按当前列出的条目共有 21 个，还包括 Asana、Canva、Slack、Lovable、Monday.com、Crossbeam 和 Unblocked 等。14 个是 Claude-issued beta 的子集，不是 EMA 的全部。如果要用不依赖 IdP 的 Claude-issued 路径，目前只能从这 14 个里选。
称，公司与 Anthropic 合作参与这次 beta，并强调「即使你的身份提供方还不支持企业托管授权」也能用。Atlassian 的 在回复中表示，团队参与了这项工作；他写道，依赖终端用户授权来构建跨 SaaS（软件即服务）体验「充满摩擦」。这些是参与方的说法，不是对功能效果的独立验证。
Amplitude 的说法点出了 Claude-issued 的实际好处：它不要求身份提供方先支持 EMA。对没有 Okta、或者不想先做 IdP 集成的组织，这省掉了 IdP 集成的一步；代价是它只覆盖 14 个连接器，而且仍是 beta。
只验证成员身份，不验证 SSO 或 MFA
Claude-issued 的信任边界写在帮助文档里：使用这条路径时，Claude 只检查组织成员身份，不检查 SSO、多因素认证（MFA），也不检查连接器自己的登录规则。Anthropic 仍然建议组织为 Claude 启用 SSO。断言证明的是「这个人是当前 Claude 组织的成员」，不是「这个人通过了公司 IdP 的 SSO」。
Claude-issued 路径按邮箱匹配用户。Anthropic 会按组织指示，把每位成员的邮箱和一个唯一标识发给连接器；成员的 Claude 邮箱必须和连接器账号的邮箱一致，否则不会自动连接，成员会看到通常的 Connect 提示。连接器按邮箱找用户；找不到时，它可以拒绝请求，或者只在邮箱域名已经验证时创建用户。
移除成员是另一个需要提前处理的环节。Claude 只给当前成员签发断言；成员被移出组织后，Claude 不再为他签发。但已经发出的访问令牌不会立刻失效，而是持续到连接器的令牌过期或被撤销。帮助文档提醒管理员，在邮箱被重新使用前，把这个人从每个连接器里移除；否则，新来的人可能用同一个邮箱登进旧账号。如果组织用 SCIM（跨域身份管理系统）目录同步，还要注意：目录删除成员时 Claude 会移除他，但目录只是暂停或标记不活跃时不会。
IdP-managed 路径的撤销更直接：身份提供方移除成员，连接器访问同时被移除。Claude-issued 路径把这件事拆成两步：Claude 停止签发，连接器里的访问要等令牌过期或被撤销。令牌生命周期由连接器的授权服务器管理，IdP-managed 路径还受身份提供方影响；现有会话在访问令牌过期或被撤销时结束。
这套设计把授权动作前置到管理员和连接器；用户端的验证强度没有提高。安全团队需要分别评估成员身份是否足够，以及连接器的权限范围和令牌生命周期是否可接受。
插件开发者要补的那一段验证
自动连接只对声明支持该扩展的 MCP 服务器生效。MCP 的企业托管授权扩展是选择加入（opt-in）的，默认不启用；连接器要在授权元数据里声明支持，客户端也要声明支持。对插件开发者来说，主要工作在授权服务器：它必须把 Claude 的 issuer URL 注册为该工作区的可信发行方，并能接受 JWT bearer grant、验证签名和各项声明。
开发者文档列出的检查包括：iss 必须与工作区注册的可信发行方完全一致；从 <iss>/.well-known/openid-configuration 取 jwks_uri，只用该密钥集验签；接受 ES256 和 RS256，拒绝 none 和 HMAC；typ 必须是 oauth-id-jag+jwt；aud 必须等于授权服务器自己的 issuer；client_id 必须与请求一致；sub 必须存在；exp、iat、nbf 要检查；jti 要防重放。任何一项失败，都按 invalid_grant 拒绝。
还有两个实现约束：EMA 不支持动态客户端注册（DCR），授权服务器必须在第一条断言到达前就认识这个客户端；不需要认证的 MCP 服务器不适用，因为它不会返回 401，Claude 没有交换断言的时机。反过来，支持延迟认证（lazy authentication）的服务器可以在返回 401 后让 Claude 自动完成交换并重试，而不是弹出 Connect 卡片。
开发者可以用一个 Team 或 Enterprise 组织做端到端测试；确认无误后，发邮件到 mcp-review@anthropic.com，让 Anthropic 把目录列表标记为支持 EMA。帮助文档说，任何 MCP 提供商都可以加这项支持。
上述功能、适用范围和名单来自 Anthropic 的公告与帮助文档，属于发布方口径。公告和帮助文档都没有给出 beta 转正式版的时间表；Okta 之外的身份提供方，帮助文档只说「即将支持」。不在 Claude-issued 名单里的连接器，如果支持 IdP-managed，组织可以走那条路；否则只能让成员自己授权。