{
  "slug": "mcp-enterprise-managed-authorization",
  "title": "MCP Enterprise-Managed Authorization: Zero-Touch SSO via ID-JAG (SEP-990)",
  "description": "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",
  "tags": [
    "mcp",
    "oauth",
    "authentication",
    "identity",
    "security",
    "agents",
    "sso"
  ],
  "updated": "2026-08-09",
  "premium": false,
  "canonical": "https://changegamer.ai/resources/mcp-enterprise-managed-authorization",
  "markdown": "https://changegamer.ai/resources/mcp-enterprise-managed-authorization.md",
  "outline": [
    {
      "depth": 2,
      "text": "Key facts",
      "anchor": "key-facts"
    },
    {
      "depth": 2,
      "text": "What an agent/client builder should do",
      "anchor": "what-an-agent-client-builder-should-do"
    },
    {
      "depth": 2,
      "text": "Verified sources",
      "anchor": "verified-sources"
    }
  ],
  "related": [
    {
      "slug": "mcp-server-authentication",
      "title": "MCP Server Authentication: OAuth 2.1 for Remote Servers",
      "description": "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.",
      "url": "https://changegamer.ai/resources/mcp-server-authentication"
    },
    {
      "slug": "agent-identity-authentication",
      "title": "Agent Identity and Authentication",
      "description": "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.",
      "url": "https://changegamer.ai/resources/agent-identity-authentication"
    },
    {
      "slug": "agent-delegation-chains",
      "title": "Agent Delegation Chains: Credential Propagation in Multi-Agent Systems",
      "description": "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.",
      "url": "https://changegamer.ai/resources/agent-delegation-chains"
    },
    {
      "slug": "ai-supply-chain-provenance",
      "title": "AI Supply Chain Provenance: SBOMs, SLSA, and Artifact Signing for Agents and MCP Servers",
      "description": "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.",
      "url": "https://changegamer.ai/resources/ai-supply-chain-provenance"
    }
  ],
  "furtherReading": [
    {
      "slug": "mcp-enterprise-sso-id-jag",
      "title": "Zero-Touch Enterprise Authorization for MCP Servers: ID-JAG and SEP-990",
      "description": "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.",
      "url": "https://changegamer.ai/articles/mcp-enterprise-sso-id-jag"
    },
    {
      "slug": "mcp-oauth-implementation",
      "title": "How to Implement OAuth 2.1 for an MCP Server",
      "description": "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.",
      "url": "https://changegamer.ai/articles/mcp-oauth-implementation"
    }
  ],
  "body": "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.\n\n## Key facts\n\n- 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.\n- 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.\n- 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.\n- 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.\n- 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.\n\n## What an agent/client builder should do\n\n1. 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.\n2. 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.\n3. 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.\n\n## Verified sources\n\nPrimary (fetched directly this session):\n\n- 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/\n- SEP-990 issue (title, `accepted`/`final` labels, problem statement): https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990\n- 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\n\nSee also: /resources/mcp-server-authentication, /resources/agent-identity-authentication, /resources/agent-delegation-chains.",
  "sources": [
    "https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/",
    "https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990",
    "https://github.com/modelcontextprotocol/python-sdk/issues/1593"
  ]
}