MCP Enterprise-Managed Authorization: Zero-Touch SSO via ID-JAG (SEP-990)
What Enterprise-Managed Authorization is: the MCP extension (SEP-990) that lets an IdP grant MCP server access during SSO instead of a per-server OAuth consent screen — the ID-JAG mechanism, the RFCs it builds on, and how it layers on standard MCP OAuth 2.1.
Standard remote-MCP auth (see /resources/mcp-server-authentication) makes a user click through an OAuth consent screen for every MCP server, one at a time, with no central admin visibility into which servers are in use. Enterprise-Managed Authorization (EMA) is the official MCP extension that removes that per-server prompt: an organization's identity provider (IdP) grants access to approved MCP servers as part of a user's normal single sign-on, so a first login connects every pre-approved server with zero additional clicks.
Key facts
- EMA is SEP-990 ("Enable enterprise IdP policy controls during MCP OAuth flows"), an accepted MCP extension proposal (GitHub label:
final), and reached stable status on June 18, 2026, per the MCP project's own blog. - The mechanism is an Identity Assertion JWT Authorization Grant (ID-JAG): during SSO, the IdP issues the client an ID-JAG (obtained via RFC 8693 Token Exchange) asserting the user's identity and entitlement to a specific MCP server; the client presents that ID-JAG to the MCP server's Authorization Server and exchanges it for an access token using an RFC 7523 JWT Bearer grant — no interactive consent screen shown to the user.
- Launch adopters named on the MCP blog: Okta as the first supporting IdP (via its Cross App Access / XAA protocol); Anthropic (Claude) and Microsoft (VS Code) as clients; Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase as MCP servers, with Slack support in progress.
- EMA is optional and additive: it changes only how the initial grant is obtained. A server or client that does not implement it falls back to the standard interactive OAuth 2.1 flow already documented at /resources/mcp-server-authentication — same RFC 9728/8414 discovery chain, same audience-binding and token-passthrough rules once a token is issued.
- It solves two named problems at once: end users no longer authorize each server individually, and enterprise admins get centralized, IdP-level policy control over which MCP servers are usable at all — rather than that decision being made ad hoc by each user.
What an agent/client builder should do
- Do not assume every MCP server needs an interactive OAuth popup — check whether the server and the caller's IdP both support EMA before building a consent-screen flow.
- Where EMA is unsupported, the standard per-user OAuth 2.1 + PKCE flow still applies unchanged — EMA is a faster on-ramp to the same Resource Server model, not a different one.
- Treat IdP-level EMA policy as a trust boundary: a compromised or over-broad IdP policy grants access to every server it lists, so the same least-privilege and audit discipline urged in /resources/agentic-security-checklist applies at the IdP-policy layer too.
Verified sources
Primary (fetched directly this session):
- MCP blog, "Enterprise-Managed Authorization: Zero-touch OAuth for MCP" (launch date, problem statement, ID-JAG flow, adopters): https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
- SEP-990 issue (title,
accepted/finallabels, problem statement): https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990 - Python SDK tracking issue (RFC 8693 Token Exchange, RFC 7523 JWT Bearer Grant, server-side JWT validation requirements): https://github.com/modelcontextprotocol/python-sdk/issues/1593
See also: /resources/mcp-server-authentication, /resources/agent-identity-authentication, /resources/agent-delegation-chains.