MCP SSO
MCP SSO is single sign-on that covers Model Context Protocol (MCP) servers: employees and agents authenticate through the enterprise identity provider they already use, and access to approved servers is granted from that IdP instead of a consent screen per server. Directory group and account changes can then govern MCP access.
MCP SSO becomes a practical issue as MCP clients spread through an organization. An employee connecting Claude or an IDE to GitHub, Jira, and an internal billing server may face a separate OAuth consent screen for each one. Where a server does not support OAuth, the employee may use a personal access token instead. Security teams that already manage access through Okta or Entra need the same central control for MCP servers.
There are two ways to provide that control. Enterprise-Managed Authorization (EMA) lets supporting MCP servers grant access from the identity provider. An MCP gateway can extend the same IdP to servers that do not support EMA.
This guide explains the role of each approach and where each applies.
Why doesn’t MCP OAuth scale across an enterprise?
The standard MCP authorization model is user-scoped and interactive. Each user authorizes each client-server pair through an OAuth consent flow. That creates three operational problems:
- Onboarding takes manual work. Every new employee connects every server they need.
- Access policy is fragmented. Each user authorizes servers separately, leaving security teams without one policy or audit trail.
- Work and personal accounts can mix. The standard flow does not require the user’s corporate identity.
The friction can lead people to use personal access tokens instead. Those tokens sit outside the directory and may outlive the employee who created them. An SSO portal does not remove per-server authorization by itself: it can authenticate the user at the portal while servers that require OAuth still prompt for their own authorization.
What is enterprise-managed authorization (EMA)?
Enterprise-Managed Authorization (EMA) is the MCP extension
io.modelcontextprotocol/enterprise-managed-authorization. It was proposed in SEP-990. EMA makes the organization’s
identity provider the decision-maker for MCP server access. Administrators
define policy in the IdP, which grants or denies access based on group
membership, role, and conditional access rules.
During single sign-on, the client obtains an Identity Assertion JWT Authorization Grant from the IdP and exchanges it for an access token at the MCP server’s authorization server. The client does not redirect the user through a per-server consent screen. Access follows the IdP policy, and administrators revoke it from the same console.
At the stable launch, Okta was the first supported identity provider through Cross App Access (XAA). Anthropic added EMA to its shared MCP layer for Claude, Claude Code, and Cowork, while Visual Studio Code added IDE support. Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase supported EMA on the server side, with Slack actively adding it.
EMA is opt-in. The core MCP 2026-07-28 authorization model remains interactive OAuth unless both the client and server negotiate the extension. Servers that have not implemented EMA continue to use their existing authorization flow.
If EMA is SSO for MCP, why do you still need a gateway?
EMA decides which users and clients may connect to which MCP servers. The IdP makes that decision when the client requests access to a server. It does not evaluate individual tool calls against the caller’s role, inspect arguments or results for sensitive data, defend against prompt injection, or discover MCP servers that employees have configured outside the sanctioned path.
An MCP gateway provides a decision point on every call. EMA governs who can access a server, while the gateway governs what the client may do through that server. MCP security covers the security controls that the authorization specification does not provide.
How do you extend SSO to MCP servers that don’t support EMA?
Many MCP estates include internal servers and SaaS servers that still authenticate with personal access tokens, API keys, or a custom OAuth proxy. Waiting for each server to implement EMA leaves those servers outside the IdP.
An MCP gateway connects MCP clients to the directory and the servers behind it. It presents one OAuth 2.1 authorization surface, with PKCE and dynamic client registration, and federates login to the IdP. SAML or OIDC handles upstream IdP authentication, while MCP clients continue to hold OAuth tokens because MCP has no SAML binding.
Behind the gateway, each server can keep its existing credential, but the credential is stored in the gateway rather than on employee laptops. The IdP decides who can use it, and directory roles govern access across the fleet. Our guide on extending IAM to agents explains how existing groups and permissions apply to agent traffic.
How does the Speakeasy AI Control Plane deliver MCP SSO?
The Speakeasy AI Control Plane provides the gateway route as a product. It connects Okta, Entra ID, and SAML or OIDC providers, and access follows the roles and permissions already defined in the directory. Every server behind the gateway receives OAuth 2.1 with dynamic client registration and PKCE. Claude and VS Code then complete one grant at the gateway, backed by the IdP login, rather than one per server.
Client access binds to a directory identity rather than a shared service account. Credentials are short-lived and scoped, as described in agent identity and task-scoped credentials. The gateway also enforces directory grants on every tool call, which is the layer EMA does not cover.
Speakeasy does not implement the EMA ID-JAG exchange. It puts the IdP in charge of servers that have not implemented EMA, so the same directory policy can govern MCP access across the estate. Governing agent actions with enterprise identity shows that model in production. To see your own IdP granting MCP access, talk to us.