Enterprise-Managed Authorization

​

What it is

• Employees shouldn’t need to understand the authorization details of every MCP server their organization uses
• Security teams can’t enforce consistent access policies if each user authorizes independently
• Onboarding new employees requires them to manually authorize dozens of services
• Offboarding requires revoking access across every service individually

​

When to use it

• Deploying MCP in a corporate environment where IT manages access to all business applications
• Enforcing organizational access policies — you need to ensure only authorized employees access specific MCP servers
• Centralizing access control — you want to add or revoke access to MCP servers from a single admin console
• Meeting compliance requirements — your organization needs an auditable authorization trail for all MCP server access
• Simplifying employee experience — employees should access MCP tools with their existing corporate SSO credentials, without per-service authorization flows

​

How it works

1. Centralized policy: The enterprise IdP maintains a registry of approved MCP servers and the access policies for each. Administrators configure these in their existing identity management tools.
2. Single sign-on: Employees authenticate with their corporate credentials once. The IdP issues tokens that grant access to approved MCP servers without additional per-server authorization prompts.
3. Policy enforcement: The IdP evaluates access policies (group membership, role assignments, conditional access rules) before issuing tokens. Employees who lack authorization receive an appropriate error — the MCP client never receives a token for unauthorized servers.
4. Centralized revocation: Revoking an employee’s access to MCP servers happens at the IdP level, taking effect immediately across all MCP clients. No per-client, per-server revocation needed.

​

Implementation guide

​

For MCP clients

1. Declare support in the initialize request:

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/enterprise-managed-authorization": {}
    }
  }
}

2. Support SSO — users should authenticate to the MCP Client using the enterprise IdP. Save the Identity Assertion (either an OpenID ID Token or SAML assertion) issued during login for later use.
3. Handle ID-JAGs — when the server indicates that enterprise-managed auth is required, request an ID-JAG token from the enterprise IdP’s authorization endpoint using the previously obtained Identity Assertion. Exchange this ID-JAG for an access token from the MCP Authorization Server. Do not redirect the user to the MCP Authorization Server’s authorization endpoint.
4. Support organization configuration — allow administrators to configure the enterprise IdP’s endpoints, typically via organization-level settings rather than per-user settings.
5. Respect token scopes — tokens issued by enterprise IdPs may have scope restrictions that differ from standard MCP authorization. Handle scope errors gracefully.

​

For MCP servers

1. Declare the extension in your server’s authorization metadata, indicating that clients must use the enterprise-managed flow.
2. Integrate with IdP admin APIs (optional) — publish your server’s resource descriptor so enterprise administrators can configure access policies in their IdP admin console.

​

For MCP Authorization Servers

1. Validate ID-JAGs issued by the enterprise IdP. This typically means validating JWT signatures against the IdP’s JWKS endpoint and checking the token’s audience, issuer, and expiration.
2. Map IdP claims to permissions — ID-JAG tokens carry claims (scope and resource information) that your server uses to determine who the employee is and what the employee can access. Define your authorization logic based on these claims.
3. Handle Account Linking - ID-JAG tokens will always contain a subject claim and may additionally contain an email claim that can be used to

​

Client support

​

Related resources