MCP Enterprise Auth (EMA): How Centralized OAuth Works for MCP Servers

The MCP 2026-07-28 Release Candidate stabilizes the Enterprise-Managed Authorization (EMA) extension — a standardized way for organizations to control access to MCP servers through their existing identity provider. Anthropic, Microsoft, and Okta have already adopted it. Here's what EMA is, how it works, and what it changes for teams deploying MCP in production.

Why auth was MCP's biggest production gap

The original MCP specification was largely silent on authentication. The protocol defined how clients and servers communicate, but left auth as an implementation detail for each server to handle independently. In practice, this meant every MCP server rolled its own approach: API keys passed in headers, OAuth flows with custom implementations, or no auth at all.

For individual developers connecting their own tools, this was fine. For enterprise IT teams deploying MCP across dozens of internal tools and hundreds of employees, it was a compliance nightmare. Each MCP server was a separate access control surface: separate credentials, separate audit logs, separate provisioning and deprovisioning workflows, separate security review.

EMA centralizes this. Instead of each MCP server managing its own auth, all servers in an organization delegate authentication to a shared identity provider. The organization manages access in one place; individual servers just verify tokens.

How EMA works

EMA builds on standard OAuth 2.1 and OpenID Connect. The flow has three parties: the MCP client (Claude Desktop, Cursor, etc.), the MCP server, and the organization's EMA provider (their identity platform — Okta, Azure AD, Google Workspace, etc.).

The high-level flow:

1. Registration. The organization registers their EMA provider with their MCP deployment. This is a one-time configuration step — a well-known endpoint URL and a public signing key.

2. Token issuance. When an employee uses an MCP client, the client requests an EMA token from the organization's identity provider. The employee authenticates with SSO (SAML, OIDC — whatever the org uses). The identity provider issues a signed JWT containing the employee's identity and the MCP server they're authorized to access.

3. Token presentation. The MCP client includes the EMA token in its requests to the MCP server, in the Authorization header.

4. Verification. The MCP server verifies the token against the organization's registered public key. No call to a central auth service is required — verification is local. The token's claims tell the server who the caller is and what they're authorized to do.

// EMA token claims (decoded)
{
  "iss": "https://auth.acme.com",          // Identity provider
  "sub": "user_abc123",                    // Employee identity
  "email": "alice@acme.com",
  "mcp_server": "internal-docs.acme.com",  // Authorized server
  "scope": "tools:read",                   // Authorized capabilities
  "exp": 1754025600,                       // Token expiry
  "org_id": "org_acme"
}

What EMA gives you that API keys don't

Identity-bound access. An API key is a secret that anyone who has it can use. An EMA token is cryptographically bound to a specific employee's authenticated session. When Alice's token is used, the server knows it's Alice — not just "someone with the API key."

Automatic deprovisioning. When an employee leaves the organization, their access to all EMA-protected MCP servers is revoked through the identity provider — the same offboarding workflow that removes access to email, Slack, and every other SSO-connected service. No manual API key rotation across individual servers.

Unified audit logs. Every MCP tool call can be logged with the authenticated identity of the caller. The identity provider has a complete record of who accessed which MCP servers and when, in the same audit system as the rest of the organization's access logs.

Scoped authorization. EMA tokens carry scopes that limit what a caller can do. An employee in the support team might get tools:read access to the internal docs server but not tools:write. Authorization is managed in the identity provider, not hardcoded in the MCP server.

Implementing EMA on your MCP server

For server developers, EMA adds one verification step to the existing request handling. On each incoming request, before executing any tool:

import { jwtVerify, importSPKI } from 'jose'

async function verifyEmaToken(authHeader: string, orgPublicKey: string) {
  if (!authHeader?.startsWith('Bearer ')) {
    throw new Error('Missing EMA token')
  }
  const token = authHeader.slice(7)
  const publicKey = await importSPKI(orgPublicKey, 'RS256')

  const { payload } = await jwtVerify(token, publicKey, {
    issuer: process.env.EMA_ISSUER,
    audience: process.env.MCP_SERVER_URL,
  })

  // payload.sub is the verified employee identity
  // payload.scope lists authorized capabilities
  return payload
}

The server advertises EMA support in its server/discover response:

{
  "protocolVersion": "2026-07-28",
  "capabilities": {
    "tools": {},
    "auth": {
      "ema": {
        "wellKnown": "https://your-server.com/.well-known/mcp-ema",
        "scopes": ["tools:read", "tools:write"]
      }
    }
  }
}

The well-known endpoint returns the server's EMA configuration — which identity providers it accepts and which public keys to use for verification. MCP clients that support EMA read this endpoint and handle the token acquisition flow automatically.

EMA vs. existing auth approaches

EMA is designed to coexist with existing auth, not replace it. Most MCP servers will want to support multiple auth methods and fall back gracefully:

• EMA token — enterprise deployments with SSO
• API key — developer access, CI/CD pipelines, non-enterprise users
• No auth — public read-only tools (acceptable only for non-sensitive data)

The priority order: check for an EMA token first, fall back to API key, then decide whether to allow unauthenticated access based on the tool being called.

Client support

Claude Desktop and the Anthropic API have shipped EMA support as of the July 28 RC. When an EMA-enabled MCP server is added to Claude Desktop, and the user's organization has registered an EMA provider, Claude Desktop handles the entire token acquisition flow — the user sees their usual SSO login, not a separate auth step for the MCP server.

Cursor and Windsurf have EMA in preview. VS Code Copilot is tracking the AAIF specification for a future release.

For developer-facing MCP servers targeting individual users rather than enterprise deployments, EMA support is optional — API keys remain the practical approach for most use cases today. EMA becomes important when your MCP server handles sensitive organizational data and needs to satisfy IT procurement and compliance requirements.

When to implement EMA

You need EMA if: your MCP server accesses private organizational data, you're selling to enterprise customers who require SSO and audit logs, or you're building internal tooling that IT needs to govern centrally.

You don't need EMA if: your server returns only public data, you're building a personal or small-team tool, or your target users are individual developers who can manage API keys themselves.

The right path for most MCP server developers right now: ship with API key auth, design your auth middleware to be pluggable, and add EMA support when your first enterprise customer requires it. The EMA spec is stable enough to implement against, and the token verification logic is straightforward if you've handled JWT auth before.