Enterprise-Managed Authorization for MCP

Enterprise-Managed Authorization is an official MCP extension that lets a company's identity provider (IdP), such as Okta or Azure AD, decide which MCP servers each employee can use. Employees sign in once with corporate single sign-on (SSO). The AI app then gets access tokens for approved MCP servers without asking the employee to approve each server.

Status in the 2026-07-28 spec: extension (Stable, published in the ext-auth repository; opt-in)

It is not part of the core spec. It lives in the official ext-auth repository, which lists it as Stable with a 2026-07-28 revision. This page follows the extension overview and the 2026-07-28 extension specification, checked on 28 October 2026.

Why it exists

The core MCP authorization flow assumes each user approves each server. The authorization extensions overview explains the gap: "Requiring employees to authorize each MCP server individually creates friction and bypasses existing security controls."

The extension docs list the enterprise problems it targets. "Security teams can't enforce consistent access policies if each user authorizes independently." Onboarding means approving "dozens of services," and offboarding means "revoking access across every service individually."

The idea was introduced as SEP-990 around the 2025-11-25 release. The 2025-11-25 release post described it as "Enterprise IdP policy controls for MCP OAuth flows (Cross App Access)."

How it works

The extension spec calls itself "an application of the 'Identity Assertion JWT Authorization Grant'," an IETF draft. It uses two standard OAuth building blocks: Token Exchange (RFC 8693) and JWT Authorization Grants (RFC 7523).

The flow in four steps

1. SSO login. The employee signs in to the AI app through the company IdP, using OpenID Connect or SAML. The app keeps the resulting identity assertion.
2. Token exchange at the IdP. The app asks the IdP for an ID-JAG for one MCP server. The audience "MUST be the issuer identifier of the Resource Authorization Server." The IdP "evaluates administrator-defined policies" before answering.
3. Grant exchange at the MCP authorization server. The app presents the ID-JAG with grant_type urn:ietf:params:oauth:grant-type:jwt-bearer. The authorization server validates it and issues an access token that "MUST be audience-restricted to the MCP Server."
4. Normal MCP calls. The app uses the access token as usual.

The client docs add one firm instruction: "Do not redirect the user to the MCP Authorization Server's authorization endpoint."

What an ID-JAG contains

The ID-JAG is a short-lived JWT signed by the IdP. This payload is copied from the extension spec's example:

{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example",
  "sub": "U019488227",
  "email": "user@example.com",
  "aud": "https://auth.chat.example/",
  "resource": "https://mcp.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281970,
  "iat": 1311280970,
  "scope": "chat.read chat.history"
}

In the spec's token exchange example, the IdP returns the ID-JAG with "expires_in": 300, or five minutes.

Opting in and discovery

Clients declare support in the extensions field of io.modelcontextprotocol/clientCapabilities, inside each request's _meta. See how MCP extensions work. A client can tell an authorization server supports the profile by finding urn:ietf:params:oauth:grant-profile:id-jag in its authorization_grant_profiles_supported metadata.

Who does what

For account linking, the docs say to use the subject claim "as the primary stable identifier," and the email claim only to match accounts created earlier.

What admins can and cannot control

The extension spec gives an example policy. Users in an "engineering" group could get read-only access from an AI code editor to a source control MCP server. Users in "marketing" could get read and write access to internal documentation.

There is a clear limit. The IdP's visibility "is limited to the process of issuing the access token, but does not extend to the actual MCP traffic." For logging tool calls, you still need gateways or server-side logs. See MCP for IT leaders and MCP audit logging.

The docs also say "Centralized revocation" happens at the IdP and takes effect "immediately across all MCP clients." The docs do not spell out what happens to access tokens already issued. The spec's example access token has "expires_in": 86400, or one day, so ask your vendor how revocation reaches live tokens.

What changed across versions

The 2026-07-28 core authorization page describes such extensions as "Optional," "Additive," "Composable" and "Versioned independently," following the core versioning cycle where they can.

Common mistakes

• Assuming every AI app supports it. The docs say "Support for this extension varies by client" and is "never active by default."
• Forgetting IdP pre-registration. The spec says "The MCP client will likely need to be pre-registered with the enterprise IdP."
• Treating the IdP as an audit log. It does not see MCP traffic.
• Coarse scopes on the MCP server. IdP policy can only be as fine-grained as the scopes the server defines.

Next step

To see how this fits the core rules, return to MCP authorization: what the spec requires, or ask our MCP development team to plan SSO for your servers.

Frequently asked questions