Index
Brief.

MCP access is now an IdP problem

The MCP Enterprise-Managed Authorization extension is now stable. Anthropic, Microsoft, Okta, and a first wave of servers have adopted it. That is an architecture change, not a convenience feature.

Until recently, most MCP access was a per-user, per-server OAuth consent. The privilege decision sat with the person in the chat. EMA moves it: the enterprise identity provider is the decision-maker. The client obtains an Identity Assertion JWT Authorization Grant (ID-JAG) from the IdP and exchanges it for an access token at the MCP server’s authorization server. There is no per-server consent screen.

MCP clientIdP policyID-JAGMCP server

Three properties fall out of that. Admins authorize a server once and users inherit access by existing groups and roles. Revocation happens once at the IdP and applies everywhere. Removing the account picker makes it harder to spill data between a personal account and an enterprise one.

The risk moves with the control. You are no longer reviewing a popup. You are reviewing an IdP allowlist, group mappings, and whether the MCP server’s authorization server actually validates issuer, audience, expiry, subject, and tenant. A single over-broad IdP policy is now the blast radius.

Anthropic’s own note is the one to keep: Claude relays what the IdP issued. Scope and data access are still the identity provider’s policy and the connected service’s permissions, not Anthropic’s.

If your MCP estate is still “everyone clicks Allow”, you do not have a connector problem. You have an identity boundary you have not designed.

Sources

  1. https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
  2. https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/extensions/auth/enterprise-managed-authorization.mdx
  3. https://support.claude.com/en/articles/15537633-authorize-mcp-connectors-for-your-entire-organization
  4. https://claude.com/docs/connectors/building/enterprise-managed-auth