1. One sentence summary

Enterprise Hosting License is a part of MCPAuthorization extension, which takes the decision-making power of "whether a user can access a certain MCP server" fromeach employee himselfIn the hands of the organization, it is concentrated in the hands of the identity provider (IdP) of the organization. Employees log in once with enterprise SSO, and the IdP decides which MCP servers to release based on organizational policies. Employees no longer need to perform OAuth authorization on each server one by one.

itnoa new set of protocols, but built on OAuth 2 extension above.

2. Why is it needed?

In a standard MCP deployment, each user independently authorizes an MCP client to access an MCP server. For consumer applications, this "user-driven" model is ideal - individuals control access to their own data.

But put into an enterprise environment, this model will expose friction and security gaps:

  • Employees should not need to understand the authorization details of every MCP server used by the organization.
  • If everyone authorizes independently, security teams cannot enforce consistent access policies.
  • Onboarding new employees requires manual authorization of dozens of services.
  • When employees leave, access must be revoked on a service-by-service basis.

Enterprise Hosting Licensing by introducing the organizational IdP asauthoritative decision makerto solve these problems. An IdP (such as Okta, Azure AD, or an enterprise SSO system) centrally controls which MCP servers employees can access and under what conditions. Employees authenticate with corporate identities—the same set of credentials they use for email, Slack, and other office tools—and the IdP then grants or denies access based on organizational policies.

Applicable scenarios: Deploy MCP in an enterprise environment, need to enforce organizational access policies, want centralized add and delete access, need auditable authorization records, and want employees to directly access MCP tools with existing enterprise SSO credentials.

3. How it works

This extension creates aDelegate authorizationProcess: The enterprise IdP acts as an intermediary between MCP clients and MCP servers.

The core is a special token——Identity Assertion JWT Authorization Grant (ID-JAG for short). The process is divided into two steps: the MCP client first exchanges the ID-JAG with the enterprise IdP, and then uses the ID-JAG to exchange the access token with the authorization server of the MCP server.

sequenceDiagram
    participant UA as Browser
    participant C as MCP client
    participant IdP as enterprise IdP
    participant MAS as MCP Authorization server
    participant MRS as MCP resource server

    C-->>UA: redirect to IdP
    UA->>IdP: redirect to IdP
    Note over IdP: User login
    IdP-->>UA: IdP Authorization code
    UA->>C: IdP Authorization code
    C->>IdP: Initiate token request using authorization code
    IdP-->>C: ID token
    note over C: The user has logged in to the client<br/>client storage ID token
    C->>IdP: use ID Token exchange ID-JAG
    note over IdP: Evaluation strategy
    IdP-->>C: return ID-JAG
    C->>MAS: use ID-JAG Initiate token request
    note over MAS: check ID-JAG
    MAS-->>C: MCP access token
    loop Loop call
    C->>MRS: Call with access token MCP API
    MRS-->>C: Return response with data
    end

Four key points of the process:

  1. centralized strategy: The enterprise IdP maintains a registry of approved MCP servers and respective access policies, which administrators configure within existing identity management tools.
  2. Single sign-on (SSO): Employees authenticate once with their corporate credentials, and the token issued by the IdP can access the approved server without requiring additional authorization prompts for each server.
  3. policy enforcement: The IdP evaluates policies (group membership, role assignments, conditional access rules) before issuing a token. Unauthorized person receives appropriate error - clientNever get itToken for unauthorized server.
  4. Centralized undo: The revocation at the IdP level will take effect on all clients, without the need for client-by-client or server-by-server operations.

4. What is the relationship with OAuth 2?

In short:It inherently builds on OAuth 2, not replaces it.

MCP's core authorization specifications are based on OAuth 2.1(OAuth 2.0 plus security hardening such as mandatory PKCE). Enterprise hosting authorization is on top of the standard OAuth authorization code flowExpand, reusing the key components of OAuth:

  • The login phase still follows the standard OAuth authorization code process (authorization code → token request → ID token).
  • Used in exchange for access token OAuth 2 Token Exchange (RFC 8693, Token Exchange) The mechanism is to use ID-JAG to exchange for access token.
  • The final call to the MCP API still carries the standard OAuth Bearer access token.

Therefore, ID-JAG is a JWT-based authorization grant (grant type) and is a member of the OAuth 2 authorization grant system, rather than starting from scratch.

The only essential difference is "who makes the authorization decision": In the standard process, users are authorized directly on the MCP authorization server; in enterprise hosting mode, the client will not redirect the user to the authorization endpoint of the MCP authorization server. Instead, the enterprise IdP will first conduct policy evaluation, issue an ID-JAG, and then exchange it for a token. The protocol base is still OAuth 2, but the decision-making power is centralized in the IdP.

5. Comparison of the two processes

DimensionsStandard OAuth 2.1Enterprise hosting authorization
empower decision makersThe user himselfEnterprise IdP (IT/Security Team)
Authorization granularityPer-user, server-by-server authorizationCentralized strategy, configured in one place to take effect globally
key tokenAuthorization code → access tokenID-token → ID-JAG → access-token
Whether to redirect to the MCP authorization endpointyesNo (the IdP issues the ID-JAG instead)
Undo methodPer-client, per-server revocationRevocation at IdP level, effective globally immediately
underlying protocolOAuth 2.1 authorization code + PKCESame as OAuth 2, Extended Token Exchange (RFC 8693)
Optimum sceneConsumer applications, individual usersEnterprise environment, compliance audit, SSO

standard process

User logs in and agrees to authorize
        ↓
MCP Authorization server issues access token
        ↓
Client calls with token MCP API

Enterprise hosting process

User enterprise SSO Log in and get ID token
        ↓
IdP Evaluate strategy, issue ID-JAG
        ↓
use ID-JAG Towards MCP Authorization server changes token
        ↓
Client calls with token MCP API

6. Key points for implementation

To MCP client

  1. Statement of support--exist initialize Extension declared in request:
{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/enterprise-managed-authorization": {}
    }
  }
}
  1. Support SSO- The user is authenticated with the enterprise IdP and the identity assertion (OpenID ID token or SAML assertion) issued during login is saved for later use.
  2. Handle ID-JAG- When the server indicates that enterprise hosting authorization is required, request the ID-JAG from the IdP authorization endpoint using the previous identity assertion, and then exchange for the access token;don't wantRedirect the user to the authorization endpoint of the MCP authorization server.
  3. Supports organization-level configuration--Allow administrators to configure IdP endpoints at the organization level rather than per user.
  4. Respect token scope——The scope restrictions of IdP tokens may be different from standard MCP authorization, and scope errors need to be handled gracefully.

To MCP server

  1. declare extension——State in the authorization metadata that the client must go through the enterprise hosting process.
  2. Integrate with IdP management API (optional)——Publish server resource descriptors to facilitate administrators to configure policies in the IdP console.

Authorize server for MCP

  1. Check ID-JAG——Verify JWT signature based on IdP's JWKS endpoint, check audience, issuer, expiration time.
  2. Map IdP claims to permissions——ID-JAG carries scope and resource statements, based on which the employee identity and accessible scope are determined.
  3. Handle account linking——ID-JAG always contains a subject statement and may also contain an email statement, which can be used for account association.

7. Development Timeline

  • 2025-06-04: SEP-990 was created as a proposal with the goal of enabling enterprise IdP policy controls in the MCP's OAuth flow.
  • 2025-11-25: In this version of the MCP specification, it was officially introduced as one of the earliest "authorized extensions".
  • 2026-06-18: The official blog announces that the extension reaches stable status, ready for production environments.

One sentence conclusion: If it refers to "formally stable and available", it is June 2026;If it refers to "entering the standard", it is November 2025. It should be noted that the implementation progress of each MCP client and SDK is different. You need to check the client support matrix to see whether a certain client has been implemented.

8. Problems and risks worthy of vigilance

Most of the following areDesign-Level Tradeoffs and Potential Risks, rather than a proven flaw; whether it is an issue depends heavily on the specific IdP implementation, token lifecycle policy, and deployment method.

1. IdPs become concentrated high-value attack targets. Authorization decisions are all converged to the IdP. The advantage is centralized management and control, but the cost is that the attack surface is also concentrated - once the IdP is compromised or misconfigured, all MCP servers will be affected. The other side of centralized cancellation is centralized failure.

2. "Revoke immediately" should be discounted. What is issued to the client is an OAuth Bearer access token, which usually has an independent validity period. Unless combined with a very short TTL and token introspection, the issued access token can still be used before expiration - "immediate" refers more to "no new tokens will be issued" rather than "existing tokens are immediately invalidated".

3. Users lose knowledge and control. The value of standard OAuth is precisely that users can see what they are authorizing. When enterprise hosting takes this step away, employees may not know what data a certain MCP server has access to. It is an efficiency improvement for enterprises, but a setback for personal privacy transparency. This is an intentional trade-off, but it is worth clarifying.

4. The account connection is fragile. The specification uses subject and possibly email claims for cross-system identity matching. Using email as a basis for identity has always been a hidden danger: the email address will change, be recycled and reused, and once it is mismatched, it will be an incorrect authorization.

5. The trust chain and permission mapping are complex. The MCP authorization server must trust the ID-JAG issued by the IdP (verifying JWKS, issuer, and audience). The establishment and maintenance of this set of federated trust is not easy; and mapping coarse-grained organizational policies (groups, roles) to fine-grained MCP permissions can easily lead to "over-wide authorization."

6. Ecological maturity and fragmentation. The path of ID-JAG/token exchange is still relatively new. There are not many IdPs that can issue ID-JAG and there are not many clients that can handle it (in the early days, Okta's Cross-App Access was mainly pushing it). In addition, it is opt-in, not enabled by default, and each client has different levels of support. The short-term implementation will be fragmented, and may also result in binding to specific IdP vendors.

9. Summary

Enterprise hosting authorization makes up for the "centralized authorization" missing from MCP in enterprise scenarios: using IdP as the decision-maker and ID-JAG as the intermediate token, without breaking away from the OAuth 2 base, the per-user and per-server authorization can be turned into one configuration that takes effect globally. It significantly improves enterprise deployment efficiency, policy consistency, and auditability.

However, the costs should be clearly understood when adopting: IdP single-point risk, the actual boundary of revocation timeliness, the transfer of users’ right to know, the fragility of account association, and the immaturity of the current ecosystem. It is recommended that before introduction, a special security review be conducted around the token life cycle policy, IdP selection and federated trust configuration, and permission mapping granularity.

References