The Enterprise-Managed Authorization (EMA) extension is now stable. We’ve heard from the community that authorization and repeated consent prompts from connected MCP servers is one of the biggest pain points when it comes to managing connectivity in enterprise environments. This extension helps address this.

EMA allows organizations to control MCP server access centrally through their trusted identity provider. For end-users, this means a zero-touch setup: the MCP servers they need are connected on first login, with no per-app OAuth and nothing to configure as a one-off.

Per-user auth is high friction

The standard MCP authorization model was designed to be user-scoped and bound to the traditional interactive auth conventions. While this might work well for more general consumer scenarios where individuals decide what touches their data, this doesn’t quite scale for enterprise deployments:

• Every employee has to authorize every server individually: onboarding means manually connecting service after service.
• Security teams cannot enforce consistent policy: access is whatever each user authorized, with no central control or audit trail.
• Work and personal accounts blur together: there’s no way to require a corporate identity, so a user can connect a personal account to a work tool.

This combination of factors slows MCP adoption and pushes people toward brittle workarounds. With no universal standard for preserving shared auth state, everyone invents their own bespoke solution. The data and tools are available, but the per-user authorization tax keeps most of them switched off.

Authorize once, inherit everywhere

Enterprise-Managed Authorization makes the organization’s IdP the authoritative decision-maker for MCP server access. Administrators define the policy once and users can authenticate with their existing identity into the MCP host. The IdP can grant or deny access based on group membership, role, and conditional access rules.

Under the hood, the client obtains an Identity Assertion JWT Authorization Grant (ID-JAG) from the IdP during single sign-on and exchanges it for an access token from the MCP server’s authorization server. The user is never redirected through a per-server consent screen. Three properties fall out of that flow:

• Authorize once, inherit everywhere: admins enable a server for the org. Users get it automatically, scoped to the groups and roles they already have.
• Centralized policy and audit: access decisions live in the IdP admin console, with one auditable trail across every connector.
• Removing personal/enterprise mixups: by removing the interactive account selection step, it’s much easier to prevent data flowing between personal and enterprise accounts by mistake or compromise.

We see this as a brand new baseline for MCP in the enterprise. When users log in, their client should be connected to the tools and data they’re authorized to use with no extra steps in between.

Early adopters

This launch brought together three groups that collaborated closely on making the implementation real:

• Identity providers: Okta is the first supported identity provider. Organizations using Okta can provision MCP access to supported servers through any supported client, using Okta’s Cross App Access (XAA).
• Clients: Anthropic has implemented the extension in its shared MCP layer for Claude. Admins can authorize MCP servers for users across Claude, Claude Code, and Cowork. Additionally, Visual Studio Code has also added support for EMA right in the IDE.
• Servers: Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase now support EMA, with Slack and more actively adding support.

We’re excited for more identity providers, clients, and servers to adopt Enterprise-Managed Auth to help reduce the authorization-related fatigue and significantly improve the security and observability posture for its implementers.

“The momentum around MCP is incredible, but as we move toward an interconnected AI workforce, security can’t be an afterthought. By embedding the Cross App Access protocol into MCP as the Enterprise-Managed Authorization extension, we turn identity into a centralized governance plane and give security teams strict compliance control and users a seamless, secure experience.”

— Aaron Parecki, Director of Identity Standards, Okta

“The Figma MCP brings the power of code and canvas together so teams can move faster, explore more and ship products that stand out. As MCP adoption grows, XAA makes it easier for enterprises to scale their MCP deployments securely without slowing teams down.”

— Devdatta Akhawe, VP of Engineering, Figma

“Logging in once and automatically having all your MCP connectors automatically setup is pretty magical.”

— Tom Moor, Head of Engineering, Linear

Get involved

As with all other MCP extensions, features, and enhancements, we welcome your input. We’re encouraging clients, servers, and identity platforms to review the extension specification and add support for the new standard into their products:

• Read the requirements: the Enterprise-Managed Authorization page documents the flow for clients, servers, and authorization servers.
• Source and spec: see the ext-auth repository and the specification for the latest in EMA evolution as well as any support materials that will help you get started.

If you’re interested in discussing the extension, sharing compatibility reports, or iterating on the extension, join the EMA Interest Group.

Acknowledgements

Enterprise-Managed Authorization is the work of the MCP community: the authors of SEP-990, the maintainers of the ext-auth repository, and the identity and MCP providers who tested early implementations and pushed the spec forward. Thank you to everyone who contributed.

This is especially important in a world where clients and servers don’t have a pre-existing relationship - we can’t assume that we will always know which MCP clients will connect to which MCP servers. This design highlights two challenges that need to be addressed:

• Operational issues with managing client IDs via Dynamic Client Registration (DCR)
• Preventing client impersonation

If you’re already familiar with OAuth and the current state of client registration in MCP, skip to Two Distinct Challenges in MCP Client Registration.

Background on OAuth

A protected MCP server that implements OAuth 2.1 should allow a user to grant a client access to itself and prevent attempts to trick the user into granting access to a client they didn’t intend to use via phishing.

The authorization flow can be best described by looking at this sequence diagram:

  sequenceDiagram
   participant Client
   participant User
   participant AuthServer as Authorization Server
   participant Resource as Resource Server

   Client->>User: 1. Redirect to authorization server
   User->>AuthServer: Navigate to auth URL
   AuthServer->>User: 2. Display consent screen
   User->>AuthServer: Approve access
   AuthServer->>Client: 3. Redirect with authorization code
   Client->>AuthServer: 4. Exchange code for access token
   AuthServer-->>Client: Access token (saved)
   Client->>Resource: 5. Request with access token
   Resource-->>Client: Protected resource

This flow requires a few steps to be performed to acquire an access token:

1. The client directs the user to an authorization UI provided by the authorization server
2. The authorization server displays a consent screen to the user
3. User approves client access and the authorization server redirects the user back to the client with an access code
4. Client exchanges the access code for a set of tokens, which are cached locally
5. Client uses the access token to access the MCP server

To be able to initiate this flow, however, the authorization server first needs some basic information about the client that is kicking off the authorization process:

1. Client name: Human readable text to display in the consent screen to help the user decide whether they want to grant access.
2. Redirect URL: The destination to send the authorization code back to if the user consents.

In order to prevent a malicious client from tricking a user into granting access they didn’t intend to grant, the authorization server must be able to trust the client information it has.

For example, a malicious client could claim to be Claude Desktop on the consent screen while actually being owned by someone not affiliated with Claude Desktop developers. Seeing the client information on the consent screen, users might grant access thinking they’re authorizing the legitimate Claude Desktop, not realizing that some malicious client now has access to their account.

Improving Client Registration in MCP

For MCP users, a common pattern is to connect to an MCP server by using its URL directly in an MCP client.

This goes against the typical OAuth authorization pattern because the user is selecting the resource server to connect to rather than the client developer. This problem is compounded by the fact that there is an unbounded number of authorization servers that an MCP server may use, meaning that clients need to be able to complete the authorization flow regardless of the provider used.

Some client developers have implemented pre-registration with a select few authorization servers. In this scenario, the client doesn’t need to rely on DCR when it detects an authorization server it knows. However, this is a solution that doesn’t scale given the breadth of the MCP ecosystem - it’s impossible to have every client be registered with every authorization server there is. To mitigate this challenge, we set out to outline some of the goals that we wanted to achieve with improving the client registration experience:

1. Clients: Client developers don’t need to implement pre-registration and distribute a client ID for each authorization server MCP servers might be using.
2. Users: Users don’t need to go through a pre-registration process themselves and manually specify a client ID for every MCP server they connect to.
3. Authorization servers:

• Trust in Metadata: Authorization servers have a way to trust the metadata they associate with a client, such as name and redirect URL.
• Single Client ID per App: Authorization servers can have a single client ID per client for governance and management purposes
• Selective Allow/Deny: Authorization servers can selectively allow or deny clients based on their policies.
• Database Management: Authorization servers do not need to handle an unbounded database or expiration flows for every new client registration.

Currently, none of our existing client registration approaches satisfy all of these requirements. Pre-registration requires too much effort in a highly variable setting (unbounded number of clients connecting to unbounded number of servers), while DCR reduces effort but creates operational issues that a lot of the authorization servers are not ready to tackle yet.

Two Distinct Challenges in MCP Client Registration

After extensive discussion with MCP server implementers, we’ve identified that a few competing solutions to the registration problem were addressing two distinct issues:

1. Operational limitations of Dynamic Client Registration in open environments
2. Client identity and impersonation risks across different deployment scenarios

Challenge 1: Operational Limitations of Dynamic Client Registration

The DCR Model Mismatch

The DCR design takes the pre-registration pattern available in modern OAuth-based authorization servers and makes it available via an API. In fully open environments like MCP, DCR really puts the spotlight on a few operational challenges that an open registration endpoint introduces:

For authorization servers:

• Unbounded database growth: Every time a user connects a client to an MCP server, a new registration is created with the authorization server unless the client already has one. Registrations are also not portable, so using Claude Desktop on your Windows machine, and then jumping to Claude Desktop on macOS will create two distinct client registrations.
• Client expiry “black hole”: There’s no way to tell a client that its ID is invalid without creating an open redirect vulnerability. Clients have to implement their own heuristics for client ID management.
• Per-instance confusion: Each client instance typically gets its own client ID even when using the same application, but on different machines or across different users. From an auditing perspective, an authorization server administrator may see hundreds (if not thousands) of records for the same application without any rhyme or reason.
• Denial-of-Service vulnerability: An unauthenticated /register endpoint writes to a database within the authorization server, meaning that tenant admins now need to worry about rate limiting or policy controls (e.g., hosts allowed to register clients).

For clients:

• Extra overhead: Managing registration state and another secret beyond access/refresh tokens
• No validity checking: Can’t verify if a client ID is still valid
• Unclear lifecycle: No guidance on when to re-register or update credentials

Solution: Client ID Metadata Documents (CIMD)

Client ID Metadata Documents (CIMD), described in OAuth Client ID Metadata Document and implemented by Bluesky, elegantly sidestep these operational issues.

Instead of a registration step, clients use an HTTPS metadata URL as their client ID directly. The server fetches the metadata from the URL at authorization time:

  sequenceDiagram
   participant Client
   participant AuthServer
   participant MetadataURL

   Client->>AuthServer: Authorization request (client_id=https://app.com/oauth.json)
   AuthServer->>MetadataURL: GET https://app.com/oauth.json
   MetadataURL-->>AuthServer: {name: "App", redirect_uris: [...]}
   AuthServer->>Client: Show consent screen & continue flow

This addresses all the operational issues:

• No unbounded database growth: Servers fetch metadata on-demand (can cache for performance)
• No expiry management: The URL is the ID - it doesn’t expire
• Natural per-app model: One URL per application, not per user
• No registration endpoint: No unauthenticated write operations

The cost? Clients need to host a metadata document at an HTTPS URL. For web applications, this is trivial. For desktop applications, this typically means hosting on their backend infrastructure.

Challenge 2: Client Identity and Impersonation

The second challenge is orthogonal to the DCR vs. CIMD debate - it’s about trusting that a client is who it claims to be. This problem will exist regardless of how the registration process is implemented.

For web-based clients, trust is more straightforward, as we have an HTTPS domain that’s tied to a certificate authority. For desktop clients, if the client can’t offload its authorization to existing backend infrastructure, there is difficulty trusting the client is legitimate and unmodified.

The Trust Spectrum

We can map impersonation scenarios on two axes: attacker cost and mitigation complexity.

Low attacker cost/Low mitigation complexity: Domain-based attacks

• Attack: Register malicious callback URI and claim to be Claude Desktop
• Cost: Trick user into clicking a link and consenting
• Mitigation:
  • Restrict trusted domains/URLs
  • Show warnings for unknown domains
  • Works with both DCR and CIMD

Medium attacker cost/Medium mitigation complexity: localhost impersonation

• Attack: Run malicious app on localhost:8080, impersonate legitimate client
• Cost: Trick user into running a malicious application (plus consenting for that app to have data access)
• Problem: Desktop apps can’t hold secrets, hard to prove identity

High attacker cost/High mitigation complexity: Platform-attested applications

• Attack: Get malicious client signed by a trusted authority
• Cost: Extremely high - requires compromising certification vendor processes
• Mitigation: platform system-level attestation (future work)

Solution: Software Statements for Desktop Applications

To broadly solve the client impersonation for the middle tier as well as to prevent localhost impersonation we need signed software statements. Implementing this would require:

1. Client hosts a JSON Web Key Set (JWKS) on their backend
2. Client authenticates the user through their own flow
3. The client-owned backend service issues a short-lived, signed JWT attesting to the client’s identity
4. Client includes this JWT in the OAuth flow
5. Authorization server verifies the JWT against the trusted JWKS

This dramatically raises the bar for client impersonation, as an attacker would need to:

• Compromise the client’s backend infrastructure, or
• Successfully impersonate the client’s authentication flow

Crucially, software statements work with both DCR and CIMD. They’re not a competing solution - they’re a complementary security layer.

Future: Platform-Level Attestation

The strongest protection would be platform-level attestation, e.g. having macOS, Windows, or Android attest that a piece of software is legitimate.

Having OS-level attestation would make client impersonation unreasonably expensive. While the exact way this ties into a software statement is yet to be prototyped, the general direction is threading platform-level application identity validation through to the OAuth flow.

The Complementary Path Forward

While we’re looking at all available options, it’s important to note that we’re not choosing between solutions. We’re exploring complementary approaches for distinct problems:

For operational issues: We are looking at adding CIMD support in favor of DCR

• Keep DCR for backward compatibility
• Recommend CIMD for new implementations
• Both achieve the same authorization goal

For trust issues: Layering software statements on top

• Optional enhancement for both DCR and CIMD
• Required only when localhost impersonation is a concern
• Authorization servers choose their required trust level

Security Considerations

Both CIMD and software statements require authorization servers to make outbound HTTPS requests, potentially to untrusted domains. Implementations must:

• Prevent SSRF attacks by blocking internal network access
• Implement timeouts and size limits
• Consider caching strategies for performance
• Validate response formats strictly

If we adopt these approaches, we’ll need good best practices and SDK support to help avoid vulnerabilities and provide a easy path for implementors.

Next Steps

Discussions for these approaches are happening in the Specification Enhancement Proposals (SEP):

• SEP-991: Client ID Metadata Documents
• SEP-1032: Software Statements with DCR

Get involved: Join the conversation in Discord (the #auth-wg-client-registration channel) or comment on the SEPs directly.

A big thank to the following folks for help with this blog post: Den Delimarsky, Aaron Parecki, Geoff Goodman, Andrew Block, Pieter Kasselman, Abhishek Hingnikar, and Bobby Tiernay.