Authorization Server must validate ID-JAG and map claims
An MCP Authorization Server accepting ID-JAGs must validate the JWT signature against the enterprise IdP's JWKS endpoint and check the token's audience, issuer, and expiration; map IdP claims (scope and resource information) to permissions; and handle account linking using the always-present subject claim as the primary stable user identifier, falling back to the optional email claim to match pre-existing accounts created before enterprise-managed authorization was configured.
When to choose enterprise-managed authorization over per-user consent
Use Enterprise-Managed Authorization when deploying MCP in a corporate environment with IT-managed application access, when enforcing organizational access policies, when centralizing grant/revoke in one admin console, when compliance requires an auditable authorization trail, or when employees should reuse existing corporate SSO credentials without per-service authorization flows. The standard per-user authorization model remains preferable for consumer applications.
IdP denies unauthorized users before any token is issued
With Enterprise-Managed Authorization the IdP evaluates access policies (group membership, role assignments, conditional access rules) before issuing tokens, so employees lacking authorization receive an error and the MCP client never receives a token for unauthorized servers. Revocation happens at the IdP and takes effect immediately across all MCP clients without per-client or per-server revocation.
OAuth Client Credentials extension identifier
The OAuth Client Credentials extension for MCP is identified by the string `io.modelcontextprotocol/oauth-client-credentials`. It adds the OAuth 2.0 client credentials flow (RFC 6749 section 4.4) to MCP so automated systems can connect to MCP servers without interactive user authorization.
When to use client credentials instead of interactive OAuth
Use the OAuth Client Credentials extension when there is no human present: background services calling MCP tools on a schedule or on events, CI/CD pipelines invoking MCP servers, server-to-server backend integrations, and daemons/long-running workers needing persistent access. If a human user should explicitly authorize access, use the standard MCP authorization flow (browser redirect + consent) instead.
Two credential formats: JWT bearer assertion vs client secret
The MCP client credentials extension supports two credential formats. JWT Bearer Assertions (RFC 7523, recommended) have the client sign a token with its private key; the authorization server validates the signature against the client's registered public key. Client Secrets use the plain client_credentials grant with client_id and client_secret posted to the token endpoint. JWT assertions are preferred because they are short-lived and never transmit the signing key.
JWT assertion claims for client credentials
A JWT bearer assertion used for MCP client credentials typically includes: `iss` = client ID (issuer), `sub` = client ID (subject being authenticated), `aud` = the authorization server's token endpoint URL, `exp` = expiration time, and `iat` = issued-at time. It is posted to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer and assertion=<signed JWT>.
Client secrets are long-lived: storage and rotation rules
Client secrets are long-lived credentials granting access without user interaction; a leak lets an attacker silently authenticate as the application until rotation. Store secrets in a secrets manager, never in source code or env files committed to version control; rotate on a regular schedule and immediately after suspected compromise; scope credentials to the minimum permissions required; prefer JWT assertions where possible.
MCP authorization extensions live in ext-auth repo
Official MCP authorization extensions beyond the core spec are hosted in the modelcontextprotocol/ext-auth repository (https://github.com/modelcontextprotocol/ext-auth), which contains specifications and reference implementations. The core MCP authorization framework is based on the OAuth 2.0 authorization code flow, where a user interactively grants an MCP client permission to access a server on their behalf.
Two auth extensions: OAuth Client Credentials and Enterprise-Managed Authorization
Two authorization extensions exist: (1) OAuth Client Credentials — machine-to-machine authentication using the OAuth 2.0 client credentials flow with no user interaction; (2) Enterprise-Managed Authorization — centralized access control where employees access MCP servers through their organization's identity provider (IdP).
Choosing an MCP auth extension by scenario
Use OAuth Client Credentials for a background service or daemon accessing an MCP server, a CI/CD pipeline calling MCP tools, or server-to-server API integration. Use Enterprise-Managed Authorization for enterprise employees accessing MCP servers at work and for organization-wide MCP access policy enforcement. For standard interactive user authorization, use the core MCP spec with no extension needed.
Why core OAuth flow is insufficient for some MCP deployments
The core MCP OAuth 2.0 authorization code flow does not fit two cases: machine-to-machine integrations (background services, CI pipelines, automated workflows) that have no human in the loop for interactive consent, and enterprise environments with centralized identity providers where requiring employees to authorize each MCP server individually creates friction and bypasses existing security controls.
Namespace authentication uses reverse-DNS names tied to GitHub or domains
MCP Registry server names follow a reverse DNS format such as `io.github.username/server` or `com.example/server`, tying each server to a verified GitHub account or domain. Only the legitimate owner of that GitHub account or domain can publish under that namespace. Ownership is verified through GitHub, DNS, or HTTP challenges.
Registry delegates security scanning to package registries and aggregators
The MCP Registry does not scan server code. Security scanning is delegated to the underlying package registries (npm, PyPI, Docker Hub, etc.) and to downstream aggregators/marketplaces, which may add extra security checks, ratings, or curation. The registry itself focuses only on namespace authentication and metadata hosting.
Registry spam prevention: character limits and manual takedown
The MCP Registry prevents spam through namespace authentication requirements (GitHub, DNS, or HTTP challenges), strict character limits and regex validation on free-form metadata fields, and manual takedown of spam or malicious servers by maintainers per the Moderation Policy. Future measures under consideration include stricter rate limiting, AI-based spam detection, and community reporting.
How to report spam, malicious servers, or registry vulnerabilities
To report a spam or malicious MCP server: first report it as abuse to the underlying package registry (NPM, PyPI, DockerHub, etc.), then raise a GitHub issue on the MCP registry repo with a title beginning 'Abuse report: '. Security vulnerabilities in the registry itself should follow the MCP community SECURITY.md at github.com/modelcontextprotocol/.github.
Do not rely on MCP Registry moderation for server trust
The MCP Registry makes no guarantees about moderation and consumers should assume minimal-to-no moderation; in-depth vetting is delegated to upstream package registries (NPM, PyPI, Docker) and downstream subregistries. Content that should be removed under the policy may still be present, so any client that installs servers from scraped registry data must apply its own trust and security checks.
Inspector host binding defaults and DANGEROUSLY_BIND_ALL_INTERFACES
By default the Inspector binds `localhost` and accepts requests only from the loopback origins for its port; both are security boundaries because the backend spawns processes on the machine. Binding all interfaces with `HOST=0.0.0.0` is refused unless `DANGEROUSLY_BIND_ALL_INTERFACES=true` is set. Binding a specific non-loopback address is allowed with no opt-in, since it is a single deliberate exposure.
Residual risks remain after implementing consent dialogs
Even with consent controls in place, residual risks include users approving malicious commands despite warnings, sophisticated obfuscation by advanced attackers who craft commands that appear legitimate, and implementation gaps where clients may implement controls incorrectly. These risks are addressed through clear warning language in consent dialogs, recommendation for additional security layers like sandboxing and signatures, and ongoing security research and community awareness.
SEP-1024 addresses one-click MCP server installation security vulnerabilities
SEP-1024 is a Final standards track document created on 2025-07-22 by Den Delimarsky that establishes security requirements for MCP clients supporting one-click installation of local MCP servers. The SEP addresses critical vulnerabilities including silent command execution without user review, lack of visibility into what commands are being executed, social engineering vulnerabilities from comfortable execution of unscrutinized commands, and arbitrary code execution through malicious embedded commands in MCP server configurations.
Clients like VS Code and Cursor implement consent dialogs for MCP server installation
Visual Studio Code and Cursor both implement consent dialogs for one-click local MCP server installation to address security concerns around command execution.
Security benefits of MCP client consent requirements
Mandatory consent dialogs directly address arbitrary code execution by preventing silent execution of malicious commands, reduce social engineering by forcing users to consciously review commands before execution, create visibility into MCP server installation commands to prevent supply chain attacks, and allow users to identify and reject commands requesting elevated privileges to prevent privilege escalation.
$ref dereferencing security risk: SSRF and fetch DoS
JSON Schema 2020-12 permits $ref to point at an absolute URI, not just a JSON Pointer into the same document. A naive implementation that resolves every $ref by issuing an HTTP request gives an attacker a server-side request forgery / fetch amplification primitive: a malicious tool definition can cause the host to fetch arbitrary URLs, including internal metadata endpoints or large payloads designed to exhaust resources. Implementations MUST NOT automatically dereference $ref values that resolve to a network URI (anything that is not a same-document JSON Pointer like #/$defs/Foo). Implementations MAY offer an opt-in mode that fetches non-local $refs, but it MUST be disabled by default and SHOULD enforce an allowlist of hosts, reject loopback/link-local/private network addresses, apply timeouts and size limits, and log dereferenced URIs. Schemas that fail to validate due to an unresolved external $ref SHOULD be rejected rather than silently treated as permissive.
Server security requirements for tools
Servers MUST: (1) validate all tool inputs, (2) implement proper access controls, (3) rate limit tool invocations, and (4) sanitize tool outputs.
Sensitive parameters should not use x-mcp-header
Server developers SHOULD NOT mark sensitive parameters such as passwords, API keys, tokens, or personally identifiable information (PII) with x-mcp-header, as header values are visible to network intermediaries.
Client security requirements for tools
Clients SHOULD: (1) prompt for user confirmation on sensitive operations, (2) show tool inputs to the user before calling the server to avoid malicious or accidental data exfiltration, (3) validate tool results before passing to LLM, (4) follow $ref resolution requirements when validating tool inputs and outputs against inputSchema and outputSchema, (5) implement timeouts for tool calls, and (6) log tool usage for audit purposes.
Tool annotations are untrusted from untrusted servers
For trust and safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers.
Human in the loop for tool invocations
For trust and safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations. Applications SHOULD: (1) provide UI that makes clear which tools are being exposed to the AI model, (2) insert clear visual indicators when tools are invoked, and (3) present confirmation prompts to the user for operations to ensure a human is in the loop.
Prompt input validation requirement
Servers MUST carefully validate all prompt inputs and outputs to prevent injection attacks or unauthorized access to resources.
MCP clients MUST show full command before local server installation
MCP clients that support one-click local MCP server configuration must display a clear consent dialog before executing any command to install or configure a local MCP server. The dialog must show the exact command that will be executed without truncation, all arguments and parameters, and a clear warning that the operation may be potentially dangerous.
MCP clients MUST require explicit user approval for server installation
Before executing any command to install or configure a local MCP server, the MCP client must require explicit user approval through an affirmative action such as a button click or checkbox, and must provide an option for users to cancel the installation. The client must not proceed with installation if consent is denied or not provided.
SEP-1024 addresses silent command execution vulnerability in MCP clients
SEP-1024 (MCP Client Security Requirements for Local Server Installation) establishes mandatory security controls for MCP client implementations that support one-click local server configuration. The motivation addresses critical security vulnerabilities including silent command execution without user review, lack of visibility into executed commands, social engineering vulnerabilities from users becoming comfortable executing commands without scrutiny, and arbitrary code execution through malicious MCP server configurations.
SEP-1024 is final status standards track
SEP-1024 was created on 2025-07-22 by Den Delimarsky and has Final status as a Standards Track proposal.
Completion security requirements
Implementations MUST: validate all completion inputs, implement appropriate rate limiting, control access to sensitive suggestions, and prevent completion-based information disclosure.
Resource security: validate URIs, implement access controls, sanitize file paths
Servers must validate all resource URIs. Access controls should be implemented for sensitive resources. Binary data must be properly encoded. Resource permissions should be checked before operations. Servers must sanitize file paths to prevent directory traversal attacks when serving file:// resources.
$ref dereferencing security: MUST NOT automatically fetch remote URLs
Implementations MUST NOT automatically dereference $ref values that resolve to a network URI. A naive implementation that resolves every $ref by issuing an HTTP request gives an attacker a server-side request forgery / fetch amplification primitive. Only same-document JSON Pointers like #/$defs/Foo are safe. Implementations MAY offer opt-in remote $ref fetching but it must be disabled by default, enforce an allowlist of hosts, apply timeouts and size limits, and log dereferenced URIs.
Composition keyword resource use security: validate with reasonable bounds
Composition keywords (anyOf, oneOf, allOf, if/then/else) and $defs enable expressive schemas, but pathological combinations can be expensive to validate. Implementations SHOULD apply reasonable bounds such as maximum schema depth, a cap on the total number of subschemas, or a per-validation time budget to prevent a malicious tool definition from acting as a CPU DoS vector against the validator.
Streamable HTTP security: validate Origin header and bind to localhost
Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks and respond with HTTP 403 Forbidden if the Origin header is present and invalid. When running locally, servers SHOULD bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0). Servers SHOULD implement proper authentication for all connections.
The lethal trifecta in agentic workflows
The lethal trifecta describes three capabilities that when combined create conditions for data theft: access to private data, exposure to untrusted content, and the ability to externally communicate. An attacker controlling one piece of untrusted content can trick an LLM into reading private data and sending it out if the agent has all three capabilities.
Tool annotations help reason about risky combinations
Annotations that help a client understand what happens when tools are used together are more valuable than ones describing tools in isolation. For example, a client could notice a session mixes closed-world data access tools with open-world communication tools, representing the lethal trifecta risk.
Security considerations for CIMD and software statements implementation
Both CIMD and software statements require authorization servers to make outbound HTTPS requests, potentially to untrusted domains. Implementations must: (1) Prevent SSRF attacks by blocking internal network access; (2) Implement timeouts and size limits; (3) Consider caching strategies for performance; (4) Validate response formats strictly.
MCP authorization approach: complementary solutions, not competing choices
MCP is exploring complementary approaches for distinct problems rather than choosing between solutions. For operational issues with DCR: keep DCR for backward compatibility, recommend CIMD for new implementations, both achieve the same authorization goal. For trust issues: layer software statements on top as an optional enhancement for both DCR and CIMD, required only when localhost impersonation is a concern, with authorization servers choosing their required trust level.
MCP OAuth 2.1 authorization flow steps
The OAuth 2.1 authorization flow for MCP consists of five steps: (1) Client directs user to authorization UI provided by authorization server, (2) Authorization server displays consent screen to user, (3) User approves client access and authorization server redirects user back to client with authorization code, (4) Client exchanges authorization code for access tokens which are cached locally, (5) Client uses access token to access the MCP server.
Client information required by authorization server
The authorization server requires two pieces of basic information about the client before initiating OAuth flow: (1) Client name—human readable text to display in the consent screen to help user decide whether to grant access, (2) Redirect URL—the destination to send the authorization code back to if user consents.
Client impersonation risk in OAuth consent screens
A malicious client can trick users by claiming to be a legitimate client like Claude Desktop on the consent screen while actually being owned by someone not affiliated with the legitimate developers. Users may grant access thinking they are authorizing the legitimate client when they are actually authorizing a malicious client with account access.
MCP client registration challenges with DCR
Dynamic Client Registration (DCR) in fully open MCP environments creates several operational challenges for authorization servers: (1) Unbounded database growth—every time a user connects a client to an MCP server, a new registration is created unless the client already has one; registrations are not portable so the same application on different machines creates multiple registrations; (2) Client expiry black hole—there is no way to tell a client that its ID is invalid without creating open redirect vulnerability; (3) Per-instance confusion—each client instance typically gets its own client ID even when using the same application on different machines or users, creating hundreds or thousands of records for the same application; (4) Denial-of-Service vulnerability—an unauthenticated /register endpoint writes to database within authorization server, requiring tenant admins to worry about rate limiting or policy controls.
DCR overhead for client applications
Clients using Dynamic Client Registration must handle: (1) Extra overhead—managing registration state and another secret beyond access/refresh tokens; (2) No validity checking—cannot verify if a client ID is still valid; (3) Unclear lifecycle—no guidance on when to re-register or update credentials.
Client ID Metadata Documents (CIMD) approach
Client ID Metadata Documents (CIMD), described in OAuth Client ID Metadata Document draft and implemented by Bluesky, avoid DCR operational issues by having clients use an HTTPS metadata URL as their client ID directly. The authorization server fetches metadata from the URL at authorization time instead of requiring a registration step. The metadata document contains client name and redirect URIs. This addresses operational issues because: (1) No unbounded database growth—servers fetch metadata on-demand (can cache for performance); (2) No expiry management—the URL is the ID and doesn't expire; (3) Natural per-app model—one URL per application, not per user; (4) No registration endpoint—no unauthenticated write operations. The tradeoff is that 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.
Software statements for desktop client identity verification
Software statements are signed JWT tokens that attest to a client's identity and prevent client impersonation for desktop applications and localhost impersonation. The implementation requires: (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 raises the bar for client impersonation because an attacker would need to either compromise the client's backend infrastructure or successfully impersonate the client's authentication flow. Software statements work with both DCR and CIMD as a complementary security layer.
Impersonation risk spectrum in MCP OAuth
Impersonation scenarios map on two axes: attacker cost and mitigation complexity. Low attacker cost/Low mitigation complexity involves domain-based attacks where malicious clients register callback URIs and claim to be legitimate clients like Claude Desktop; mitigation includes restricting trusted domains/URLs and showing warnings for unknown domains, working with both DCR and CIMD. Medium attacker cost/Medium mitigation complexity involves localhost impersonation where attackers run malicious apps on localhost:8080 claiming to be legitimate clients; this is difficult because desktop apps cannot hold secrets and it is hard to prove identity. High attacker cost/High mitigation complexity involves platform-attested applications where attackers must get malicious clients signed by trusted authorities; mitigation is through platform system-level attestation (future work).
EMA specification and source code location
The Enterprise-Managed Authorization specification and source code are available in the ext-auth repository at https://github.com/modelcontextprotocol/ext-auth. The specification is located at https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization.mdx.
Okta is first supported identity provider for EMA
Okta is the first supported identity provider for Enterprise-Managed Authorization. Organizations using Okta can provision MCP access to supported servers through any supported client using Okta's Cross App Access (XAA).
Anthropic and VS Code support EMA
Anthropic has implemented the Enterprise-Managed Authorization extension in its shared MCP layer for Claude, allowing admins to authorize MCP servers for users across Claude, Claude Code, and Cowork. Visual Studio Code has also added support for EMA right in the IDE.
Enterprise-Managed Authorization (EMA) extension is stable
The Enterprise-Managed Authorization extension to the Model Context Protocol is now stable. It enables organizations to centrally provision MCP server access through their identity provider so users get connected servers on first login without per-app OAuth. The extension is being adopted by Anthropic, Microsoft, Okta, and other MCP servers.
EMA flow uses Identity Assertion JWT Authorization Grant
Under the hood, Enterprise-Managed Authorization uses the Identity Assertion JWT Authorization Grant (ID-JAG) flow. The client obtains an 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.
EMA three key properties
Enterprise-Managed Authorization provides three properties: (1) Authorize once, inherit everywhere — admins enable a server for the organization and users get it automatically, scoped to their existing groups and roles; (2) Centralized policy and audit — access decisions live in the IdP admin console with one auditable trail across every connector; (3) Removing personal/enterprise mixups — by removing the interactive account selection step, it is easier to prevent data flowing between personal and enterprise accounts.
MCP servers supporting EMA
The following MCP servers support Enterprise-Managed Authorization: Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. Slack and others are actively adding support.
EMA Interest Group for community discussion
An EMA Interest Group is available at https://modelcontextprotocol.io/community/interest-groups/enterprise-managed-authorization for discussing the extension, sharing compatibility reports, and iterating on the extension.
Expedited removal for security vulnerabilities in MCP
The twelve-month minimum deprecation floor may be shortened when a feature presents an active security risk, meaning a vulnerability with a published security advisory or documented in-the-wild exploitation for which no in-place mitigation exists. Shortening the window requires Core Maintainer approval. The shortened window must still provide at least ninety days between the feature becoming Deprecated and its earliest removal.
Authorization Interest Group scope and mission
The Authorization Interest Group provides a venue for MCP implementers, identity-provider vendors, and security practitioners to surface real-world authorization challenges when deploying MCP clients and servers. The group gathers use cases, documents gaps in the current OAuth 2.1–based authorization specification, and incubates validated problems until they are scoped well enough to propose focused Working Groups via the standard group-creation process to drive SEPs.