Enterprise-Managed Authorization (EMA) is the MCP community’s answer to one of enterprise AI’s most persistent friction points: OAuth sprawl at scale. This article covers how the now-stable EMA extension works, what it leaves to the gateway and governance layer, and where tools like Obot fit in.
MCP grew fast because it allowed users to quickly stand something up and see immediate results. As with most things, this fast ease of use runs counter to what enterprises need when adopting technology at scale.
As part of the MCP specification, OAuth is the recommended authorization mechanism — a wise choice when participating on the internet to adopt a well known and familiar standard. The challenge has been that AI clients, while consumed by users, have a different usage pattern. As such, the MCP community has been pushing the boundaries of the OAuth specification to achieve a seamless user experience.
One of the friction points has been the sheer number of times a user needs to go through the OAuth flow and authorize each and every MCP server. Multiply this across an enterprise and you have a lot of servers, and a lot of users, ending up with a lot of friction.
Now the MCP community has stabilized an extension they have been working on for a while now called “Enterprise-Managed Authorization” (EMA). With EMA, enterprises can now centrally manage authorizing users to MCP servers through their identity provider (IdP).
What Enterprise Managed Authorization (EMA) is and How EMA Works
Similar to how SSO simplified SaaS authentication and authorization, the EMA extension brings that ease to MCP. In enterprise environments, administrators use an existing identity provider tied to corporate identity to authorize MCP servers at the IdP layer, define access management policies once, and assign groups of users access, while users sign in with their existing corporate credentials to get MCP server access without separate approvals.
Instead of the user needing to log in and authorize each MCP server individually, they are able to log in once and no longer need to authorize. That makes MCP access feel more like a normal work tool than a separate security hurdle, keeps a personal account distinct from company access, and helps avoid slowing teams down. The user is not presented with a stream of consent screens, which reduces friction, gives security teams centralized control to minimize unauthorized access and data breaches, and creates a secure experience as MCP adoption grows. It also helps enable MCP connectors through centralized governance, and lets organizations manage MCP deployments securely.
Now for all of this to work, the client, IdP, and MCP server all need to support the EMA extension, including support across the client, IdP, and MCP server in enterprise environments that rely on an existing identity provider.
The Token Handoff
It is worth looking at what actually happens behind that single sign-on, because the mechanics are where EMA parts ways with standard OAuth and the standard MCP authorization model. In a normal OAuth flow, the user is the one granting consent. That is the screen you click through for every server.
EMA takes that step out.
When a user signs in through the IdP, the MCP client obtains a signed assertion that vouches for two things at once: who the user is, and which application is asking for access. The client obtains that assertion from the IdP and exchanges it with the authorization server for MCP server access, which validates it and returns a scoped access token with the right scope. Because this authorization flow rides on single sign-on, short-lived tokens minimize damage in the event of a breach, and access token lifetimes can be shortened without productivity loss. From there the client uses the token to make its calls like any other API client. There is no per-server consent screen because the IdP has already made the decision.
This is all built on a token type the IETF is working to standardize, the Identity Assertion JWT Authorization Grant — ID-JAG for short — whose whole job is to let one application make a verifiable claim about a user to another, and the MCP authorization spec defines the open enterprise-managed authorization extension that makes this kind of support possible, including zero touch OAuth, across providers.
The Clean Boundary
This extension answers one question: can this user access this MCP server, while centralized policy management handles consistent enforcement across applications at finer-grained levels. It does not address finer-grained controls, like “can this user call this tool.” The IdP becomes the place to register and authorize users and groups to the broad MCP server. Finer grained decisions are still deferred to policy engines and gateways that sit between users and servers performing tool level access, audit, logging, and observability functions. Those engines can deploy policy updates centrally without modifying application code, and teams often manage authorization policies like software code under version control.
High-risk operations can still require step-up verification with explicit user confirmation. This is where a gateway layer becomes practical infrastructure rather than a future-state concern. Obot, for example, sits between users and MCP servers and handles exactly the decisions EMA leaves open: which tools a user can call, what gets logged, and whether a given request should be allowed through at all. Policy is defined once and enforced centrally across every connected server — no changes required to the MCP servers themselves.
What Comes Next
EMA gives MCP a cleaner enterprise boundary, and that opens up the rest of the problem.
Once the boundary exists, MCP servers can be treated less like one-off user connections and more like managed enterprise capabilities — discovered, approved, assigned, monitored, and governed as part of a broader operating model.
The division of labor starts to look familiar. Identity providers handle identity and coarse-grained access. AI clients are where users experience those capabilities. VS Code now supports Enterprise-Managed Authorization for MCP as a current client example. Okta is supported at launch, and Slack support is expected soon. Gateways, catalogs, and governance layers sit in between, deciding what should be available, how it should be exposed, and how usage is controlled across clients, servers, tools, and agents. Obot is an example of what that layer looks like in practice. It provides an open-source MCP gateway and curated server catalog that IT teams use to approve, expose, and monitor MCP servers across their organization. It also bridges a concrete compatibility gap EMA doesn’t address: MCP requires Dynamic Client Registration, which enterprise IdPs like Microsoft Entra don’t natively support. A gateway control plane fills that gap without requiring changes to existing identity infrastructure.
EMA doesn’t have to solve any of that. What it does is take the first messy problem — per-server authorization — off the table, so those layers can be built on a stable foundation instead of every team inventing its own workaround, with MCP connectors and broader client support able to develop on top of a consistent enterprise model.
