Per-app OAuth for MCP breaks down the moment you try to roll out more than a handful of tools: onboarding becomes a consent scavenger-hunt, security gets a fragmented audit trail, and you end up with personal accounts connected to work agents.
Enterprise-Managed Authorization (EMA) changes the centre of gravity: the IdP becomes the place you approve servers and users, and “first login auto-provisions servers” becomes a product expectation rather than a nice-to-have. EMA was marked stable on June 18, 2026, and the ecosystem is converging on the pattern. (blog.modelcontextprotocol.io)
What EMA actually changes (and what it does not)
EMA is an MCP extension that moves authorisation decisions “up” into your enterprise identity provider. Instead of every employee authorising every MCP server independently, the organisation configures which servers are allowed and under what policy (groups, roles, conditional access). (modelcontextprotocol.io)
Under the hood, the client logs the user in with enterprise SSO, obtains an identity assertion, requests an Identity Assertion JWT Authorization Grant (ID‑JAG) from the IdP, then exchanges that for an access token from the MCP server’s authorisation server. The user is not bounced through a per-server consent screen. (blog.modelcontextprotocol.io)
What EMA does not do for you:
- It does not magically make every downstream SaaS support your IdP token. You still need a story for how your MCP server talks to Jira, GitHub, Snowflake, your internal APIs, etc.
- It does not eliminate the need for a gateway. In practice, EMA increases the value of a gateway because central auth only helps if every call is actually enforced and observed.
Why “first login auto-provisions servers” changes rollout mechanics
The practical implication of EMA is simple: if an employee can sign into the host (Claude/your internal agent UI/IDE) with corporate SSO, they can be provisioned into a tool set without touching OAuth per tool.
That shifts your rollout plan from “train users to connect tools” to “treat tools like managed infrastructure”. It also changes the questions a head of engineering should ask.
Before EMA: rollout is a user behaviour problem
With per-server interactive OAuth, the default failure mode is non-adoption:
- Users do not connect the tools because they are busy.
- Users connect the wrong account (personal GitHub, personal Google Drive) because the OAuth screen allowed it.
- Security gets an approval surface that is effectively uncontrolled, because consent happens one user at a time. (blog.modelcontextprotocol.io)
With EMA: rollout becomes governance and lifecycle management
If auto-provisioning works, the primary work is no longer “getting users through flows”. It is:
- Defining which MCP servers are approved at all (your internal registry stance).
- Mapping access to groups/roles in the IdP.
- Designing what happens when access changes mid-session.
- Implementing enforcement at runtime (server-side and/or gateway-side), not just at connection time.
This is why teams are redesigning around IdP-managed provisioning and gateway enforcement rather than one-off app OAuth flows. The MCP project itself frames EMA as centralised policy and audit, with revocation happening at the IdP level across clients. (modelcontextprotocol.io)
The new failure modes you have to design for
EMA removes a class of pain (human consent loops), but it introduces sharper technical and organisational edges. These are the ones that actually show up in production.
1) Token scoping failures (and “it worked yesterday”)
Once policy is centralised, your system becomes more sensitive to scope mismatches:
- The IdP issues a token that is valid, but missing scopes the agent expects.
- A tool starts requiring additional scopes after an update.
- Your client/server disagree on required scopes for a call.
The MCP auth spec explicitly calls out dynamic scope requirements and scope errors; clients are expected to handle them (including step-up or retry patterns). (modelcontextprotocol.io)
What “do not do this” looks like:
- Do not treat a successful login as proof that all tools are usable.
- Do not fail closed with a generic “connector broken” error; you will train users to work around governance.
Design response:
- Make scope errors explicit and attributable (which tool, which scope, which policy).
- Keep tokens short-lived where you can, and build a predictable renewal path.
2) Cross-app delegation confusion (IdP is now a broker)
EMA is effectively a delegated model: the IdP sits between the client and many MCP servers and becomes the point where cross-app access is coordinated. In the EMA announcement, Okta’s Cross App Access (XAA) is called out as enabling central provisioning for supported servers through supported clients. (blog.modelcontextprotocol.io)
Operationally, this creates a new class of misconfiguration:
- The server is approved, but the wrong audience/resource is configured.
- The IdP policy allows the user, but the server’s token exchange rejects the grant.
- Multiple hosts (say, an IDE agent and a chat host) rely on the same delegated relationship and you accidentally grant broader access than intended.
Design response:
- Treat each MCP server like a production dependency with an owner, a change process, and a rollback.
- Make the “approved servers list” auditable and reviewable, like you would an API gateway route table.
3) Gateway enforcement gaps (tokens are not policy)
EMA improves who can get a token. It does not, by itself, ensure every tool call is authorised at the right granularity.
A common trap is assuming “the token is scoped, therefore safe”. In agent systems, the blast radius is often decided by:
- Which tools exist.
- Which arguments are allowed.
- Which resources a tool call is allowed to touch.
If you are serious about blast radius, you need a Policy Enforcement Point somewhere that sees the call and can block it (often a gateway, sometimes in the server). This aligns with broader guidance that MCP governance must cover both authentication/authorisation and the resources tools access. (docs.aws.amazon.com)
Design response:
- Put enforcement in the path of execution, not in the UI.
- Log the “who/what/why” per tool invocation, not just per connection.
4) Revocation semantics surprise (centralised means immediate)
EMA’s promise is centralised revocation: change group membership, and access changes across clients without chasing individual app consents. (modelcontextprotocol.io)
That is good, but it changes your runtime expectations:
- Mid-run workflows may fail because the user lost access between steps.
- Long-lived agent sessions might carry assumptions that are no longer true.
Design response:
- Make workflows resumable and idempotent where possible.
- For high-risk tools (payments, prod deploys), re-check authorisation close to the actuation point.
A pragmatic architecture that works for 20–500 people
If you are a founder or head of engineering, you want something that passes a security review without turning into a six-month IAM programme.
Here is the pattern we see teams settling on.
Step 1: Start with a gateway whether you think you need one or not
A gateway MCP server (or proxy layer) gives you a single chokepoint for:
- Authentication integration (SSO, EMA flows)
- Policy checks per tool call
- Consistent logging/trace IDs
- Rate limits and anomaly controls
This is also where you can normalise identity claims into a form your policy engine can actually use (groups/roles vary wildly by IdP).
Step 2: Use EMA for “which tools exist for this user”
EMA is excellent at provisioning:
- Which MCP servers show up for a user on first login
- Which environments are visible (prod vs staging)
- Which coarse permissions apply (engineering vs finance)
Treat that as your baseline.
Step 3: Add per-call authorisation for blast radius control
Decide what you enforce per call. At minimum:
- Tool allow/deny per role
- Resource constraints (which project, repo, database, tenant)
- High-risk argument constraints (file paths, SQL, shell commands)
This is where “token is valid” stops being the interesting question.
Step 4: Be honest about downstream SaaS auth
EMA governs access to MCP servers. But each MCP server still has to access real systems.
You generally end up with one of these approaches:
- User-delegated tokens stored server-side (more auditability in the SaaS, more operational burden)
- Service accounts gated by strict per-call policy (simpler operations, but blast radius if the server is compromised)
- Token exchange / on-behalf-of where supported (cleaner, but not universal)
The important part is to pick deliberately per system, rather than “whatever was easiest to ship”.
When EMA is the wrong answer
EMA is not a free win. It is the right direction when you have an actual enterprise identity story.
Do not lead with EMA if:
- You do not control an IdP (or your customers do not), and you cannot depend on consistent SSO.
- Your tools are mostly local/dev-only and the risk is low; per-user OAuth might be fine.
- You cannot invest in enforcement and observability. Auto-provisioning without enforcement is a faster way to roll out insecure capability.
A useful rule: if you cannot describe your blast radius per tool in one sentence, do not automate provisioning yet.
Implementation checklist (what you change in code and config)
- Decide your “system of record”: - IdP groups/roles drive tool access - A registry (even a simple config repo) maps groups → MCP servers
- Update your MCP client behaviour: - Declare EMA capability in initialise, per the extension guidance (modelcontextprotocol.io) - Store the identity assertion from SSO for later ID‑JAG acquisition (modelcontextprotocol.io)
- Update your MCP servers: - Support enterprise-managed flows (ID‑JAG exchange) if you require them - Validate audience/resource indicators properly (avoid “valid token, wrong resource”)
- Put a gateway in front of anything high-risk: - Enforce per-tool and per-argument policies - Centralise logging and incident response hooks
- Test the real operational failures: - Scope missing - Group removed mid-session - IdP outage / token endpoint throttling - Server auth metadata misconfiguration
Where codeversols fits (briefly, and honestly)
If you are redesigning MCP auth around EMA, the hard parts are rarely “implement OAuth”. They are: choosing the boundary (gateway vs server), getting revocation and scope behaviour right, and making policy enforcement observable without slowing teams down. That is the sort of systems work we do at codeversols across cloud, AI and platform engineering, typically alongside your existing team rather than replacing it.
Close
EMA’s real value is not that it saves users a few clicks. It turns MCP tool access into something you can govern centrally, roll out predictably, and revoke cleanly.
The cost is that you have to treat authorisation as a product surface: scopes, delegation, and gateway enforcement become first-class engineering concerns. If you do that work, agent rollout stops being a set of bespoke OAuth integrations and starts looking like managed infrastructure.
