# 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. Category: Reference · Updated: 2026-08-09 · Tags: mcp, oauth, authentication, identity, security, agents, sso Canonical: https://changegamer.ai/resources/mcp-enterprise-managed-authorization Variants: [HTML](https://changegamer.ai/resources/mcp-enterprise-managed-authorization) · [JSON](https://changegamer.ai/api/resources/mcp-enterprise-managed-authorization.json) License: https://changegamer.ai/license.xml · Access: free 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 1. 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. 2. 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. 3. 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`/`final` labels, 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. --- ## Related resources - [MCP Server Authentication: OAuth 2.1 for Remote Servers](https://changegamer.ai/resources/mcp-server-authentication.md): How OAuth 2.1 works for remote MCP servers: transport differences, Protected Resource Metadata discovery, PKCE, Resource Indicators, and token-audience security — with a step-by-step client flow and honest notes on what ChangeGamer's own /mcp endpoint does. - [Agent Identity and Authentication](https://changegamer.ai/resources/agent-identity-authentication.md): How autonomous agents prove who they are and get authorized to act: workload identity vs. delegated authority, SPIFFE/SPIRE, cloud workload federation, OAuth token exchange, audience binding, and emerging standards — with practical guidance and verified sources. - [Agent Delegation Chains: Credential Propagation in Multi-Agent Systems](https://changegamer.ai/resources/agent-delegation-chains.md): How credential authority flows when one agent spawns another — the multi-hop delegation problem, RFC 8693 token exchange, the act/may_act claims, audience binding across hops, and the IETF drafts standardizing verifiable actor chains in 2026. - [AI Supply Chain Provenance: SBOMs, SLSA, and Artifact Signing for Agents and MCP Servers](https://changegamer.ai/resources/ai-supply-chain-provenance.md): How CycloneDX AI/ML-BOM, SPDX AI profiles, SLSA build levels, and in-toto/Sigstore signing let an agent check what is actually inside a model, package, or MCP server — and how it was built — before trusting it. --- ## Further reading - [Zero-Touch Enterprise Authorization for MCP Servers: ID-JAG and SEP-990](https://changegamer.ai/articles/mcp-enterprise-sso-id-jag.md): How Enterprise-Managed Authorization (SEP-990) removes the per-server OAuth consent screen for MCP servers: the ID-JAG grant mechanism, its RFC 8693/7523 building blocks, named launch adopters as of August 2026, and how it layers on top of standard OAuth 2.1 rather than replacing it. - [How to Implement OAuth 2.1 for an MCP Server](https://changegamer.ai/articles/mcp-oauth-implementation.md): A wire-level implementation walkthrough for OAuth 2.1 on a remote MCP server: what the discovery documents actually contain, CIMD vs. Dynamic Client Registration in your server code, per-SEP detail from the 2026-07-28 hardening set, and token-validation mechanics. --- Index of all resources: https://changegamer.ai/llms.txt · Full corpus: https://changegamer.ai/llms-full.txt · Corpus data (NDJSON): https://changegamer.ai/api/corpus.jsonl · Offers: https://changegamer.ai/api/pricing.json