Authentication

[jaredhanson]

First of all - thanks for open-sourcing MCP and all the effort that has been put in to-date. I'm truly excited about the integration possibilities this protocol enables. Of course, a lot of those integrations will need authentication!

Since authentication and authorization are not currently part of the specification, I'm starting a discussion for this topic. I saw @alexalbertt tweeted that remote server support with enterprise-grade is being built, so I'm curious if any further details can be shared as a starting point.

[at-white]

A reflection: when the user is running the MCP server locally, auth is essentially a solved problem (just bake credentials into the server implementation). If the intention is to support a 'canonical' remote server for each different integration, there are no guarantees about what 'shape' those credentials will take. So necessarily, the protocol will need some intermediate adapter between the MCP auth abstraction and the remote service's auth abstraction.

Does this necessitate creating the concept of an MCP user identity that can be paired to remote service credentials? Perhaps the client stores credentials in local storage, and the protocol specifies where and how to extract them?

I'm just spitballing here to get the conversation started!

[jspahrsummers]

Thanks for getting the conversation started here! We've thought a bit about this, but definitely not enough to bake something into the spec yet.

A few principles we probably want to prioritize include:

• In the remote MCP case, users may trust servers with their credentials but not clients.
  • For example, an official MCP server for some web service is probably more trusted to handle tokens for that service than the end-user LLM application.
• Implementing a server should be as simple as possible. We prefer to push complexity onto clients.
• The MCP ecosystem should be open by default—that is, we want to allow custom clients and servers to interoperate with the ones we build, even if we have no knowledge of those custom implementations.
• Relatedly, we would prefer to avoid a central trust authority. We want clients and servers to be able to determine whether they trust each other based on user consent, rather than delegating to any kind of registry of trusted implementations.

This led us to brainstorm this initial shape of thing:

1. Remote MCP servers host an OAuth flow for the user (i.e., they are an OAuth client for some third party service). The authentication flow starts at an /install endpoint that initiates OAuth2. This can be accessed in two ways:

   • Directly in a browser, for interactive flows
   • Programmatically, with an optional callbackUrl parameter for headless flows

2. After OAuth completes, the browser, etc. is directed to an /oauth2callback endpoint:

   • Validates the OAuth response
   • Generates a cryptographically secure random session ID (e.g., a UUID)
   • Encrypts and stores the OAuth credentials in some storage that the server controls (e.g., Redis)
   • Either:
     • Returns the session ID directly (for API flows)
     • Or redirects to the provided callback URL with the session ID (for interactive flows)

3. For subsequent requests, clients connect to /sse with the session ID as a query parameter. The server:

   • Retrieves and decrypts the stored credentials using the session ID
   • Handles token refresh automatically when needed
   • Uses the credentials for all MCP operations

In this design:

• Sessions are long-lived (1 week) but can be explicitly revoked
• Credentials are encrypted at rest using the session ID, and session IDs are not stored anywhere—so only a client with the session ID can resume an authenticated session
• Token refresh is handled transparently to MCP clients
• Multiple server instances can share sessions via Redis

However, this maybe feels a bit too bespoke—and maybe too suspiciously similar to some OAuth variants—that there's probably a better thing to coalesce around.

[ggoodman]

It seems like there are two different authn use-cases being discussed here:

1. The MCP client (e.g. Claude Desktop) authenticating itself to an MCP Server (remote or otherwise). In your discussion above, a session identifier seems to be the mechanism for establishing both trust and identity.
2. The remote MCP Server to 3rd-party resources. My read is that your discussion above is mostly focused on this. I would suggest that while it could be part of the spec, it could also be left up to an MCP Server implementor to design in their own way. Authenticating a remote MCP Server to perform GitHub operations on my behalf could be entirely done during a pre-requisite set-up flow outside the lifecycle of the MCP protocol.

As noted above, I think that the MCP Client <--> MCP Server layer is the more interesting part of authentication to discuss.

The current quickstart in Claude Desktop invokes local binaries that are manually configured by the user. This establishes a implicit trust between the MCP Client and Server.

On the other hand, if the MCP Server is remote, then the choice of MCP Server by a User creates trust from the Client to the Server but not the other way around. How does an MCP Client authenticate itself (and the user(s) on whose behalf it is operating) to the remote MCP Server?

In this world, the remote MCP Server is designed for multi-tenancy and needs a way to establish a trust relationship with Clients to authenticate their users. I think OAuth2 can provide a good answer here. Let me speculate on a workflow:

MCP Client Authentication Flow for a Remote MCP Server

1. The User opens Claude Desktop (the Client) settings and choses to add a remote http MCP Server.
2. The Client performs a pre-flight request to the remote Server to discover authentication capabilities. It discovers that the Server supports OAuth2 auth and in so doing obtains the necessary metadata about it's configured Authorization Server (AS).
3. The Client initiates an OAuth2 flow (with scope=offline_access) with the AS indicated in the metadata. I'm pretty sure there's ample tools in the various OAuth2 flows to support headed and headless versions of this flow.
4. The Client obtains an access and refresh tokens from the AS and stores those adjacent to the configured remote MCP Server url. The Client is responsible for performing refresh token exchange as necessary to maintain a live access token. If these expire or are invalidated, a new OAuth2 flow can be initiated.

This design means that the Clients don't need to be configured with any hard-coded understanding of potential remote MCP Servers and that the Clients don't need to know anything special in order to authenticate themselves and their users.

Remote MCP Server Authn / Authz Example

On the other side of things, the value of this whole concept is granting MCP Clients access to data and capabilities so how do we do that part in a secure way? Here's an example imagining a hypothetical MCP Server-as-a-Service (MCPaaS):

1. The User visits their MCPaaS dashboard and decides to configure a new integration.
2. As part of the integration set-up flow, the User must authorize the MCP Server via OAuth2.
3. The MCP Server persists the User's credentials in its own system and maintains a relationship with the logged-in dashboard User and the credentials for this external resource.
4. When an MCP Client invokes capabilities offered by this configured integration, the MCPaaS can retrieve the credentials and perform operations on behalf of the user.

I think this is a compelling design because it means that MCP Clients only need to concern themselves with authenticating their users to the remote MCP Server. The complexity of credentials management for the capabilities offered by the remote MCP Server become an implementation detail.

[MartinSchlott]

First of all, congratulations to Anthropic on MCP! It's a significant milestone in the standardization and democratization of LLM integration into workflows.

In my personal project, I’ve been working on something similar for months—not aiming to create a standard, but specifically focusing on authentication and authorization challenges. Your perspective on MCP servers as "servers" is natural, but I believe it brings additional complexity to authentication and authorization. By shifting the perspective, the solution, in my view, becomes simpler and more streamlined.

Instead of thinking of an MCP server as a server, consider it as a "resource provider". This essentially makes it a client in its own right. Typically, consumers don’t connect to multiple servers—they connect to multiple providers or a single server. Treating the MCP server as a resource provider shifts the burden of full authorization away from each individual connection and instead shares it between client and provider.

With this perspective, OAuth 2.0 fits perfectly. Here’s how:

1. The MCP server is provided with credentials and the URI of an OAuth server. It authenticates and authorizes itself against this server, much like a client would. Alternatively, the server can be directly supplied with tokens it accepts from clients.
2. The actual connection flow between client and provider remains the same:
   • Tokens are exchanged and validated during the handshake.
   • This approach keeps the authentication and authorization logic out of the MCP protocol itself, simplifying it significantly.
3. This also means MCP servers don’t need to implement an auth server themselves, which reduces complexity.
4. By relying on OAuth 2.0, existing infrastructure and standards can be leveraged.

OAuth can handle both authentication and authorization in most scenarios. For instance:

• A trusted MCP server can obtain a token from an OAuth server using a client secret without user interaction.
• An untrusted MCP server undergoes the full OAuth flow, but the subsequent communication remains identical.
• The same applies to clients.

Importantly, identification during communication should be considered separately. For example, commands from a user with multiple open chats must be mapped to the correct threads or contexts. This should not be conflated with the auth process.

In conclusion, OAuth 2.0 is the best candidate for handling these challenges. It covers all use cases, is highly standardized, and avoids introducing bespoke solutions that may duplicate existing functionality. By keeping authorization and authentication out of the MCP protocol, the protocol remains focused, interoperable, and robust.

Additionally, in my opinion, an MCP server should offer three different modes for authentication:

1. None: The current implementation. This mode simplifies development significantly and allows developers to focus on other parts of the ecosystem without being burdened by authentication complexities.

2. Simple: At startup, the MCP server is given:

   • A token it provides at the beginning of a connection to authenticate itself.
   • A token (or a list of tokens) it accepts from clients.
     This mode is ideal for secure environments or scenarios where security is not a primary concern.

3. OAuth: At startup, the MCP server receives credentials and the necessary OAuth endpoints, enabling it to perform the full OAuth flow.
   This mode offers a robust, standards-compliant approach suitable for production environments with stringent security requirements.

These modes provide flexibility for different stages of development and deployment, while ensuring the protocol remains adaptable to varying levels of security needs.

[jspahrsummers]

Thanks, I think this good food for thought! One reason to not handle OAuth credentials on the MCP client side is that users might trust a particular server with their credentials more than a client.

For example, if I'm using a Google Drive integration with Claude, I (as the user) may prefer the Google Drive MCP server to have my Google credentials and not the Claude application. This seems to necessitate the server initiating an OAuth flow that the user participates in, but not handling Google's OAuth credentials in the MCP client.

[MartinSchlott]

Let me walk through an example. Suppose we have an MCP server called "filesystem."

1. Local Development:
   During local development, the "none" mode is used. This simplifies the process by eliminating the need for authentication and allows developers to focus on other aspects of the implementation.

2. Trusted Environment (1:1 connection):
   The client and server operate in a trusted environment, and the service is limited to a one-to-one connection. Here, the "simple" mode suffices.
   In this mode, a token (e.g., Bearer token) is configured. The server authenticates itself at the beginning of the connection using this token, ensuring a lightweight but sufficient level of security.

3. Trusted MCP Server, Untrusted Consumer (OAuth):
   In this scenario, the MCP server (e.g., the filesystem server) operates locally in a trusted environment, but the consumer does not. This is where OAuth comes into play:

   • The MCP server uses the Client Credentials Flow, which does not require user interaction.
   • The responsibility of determining who is authorized to access the service lies with the OAuth server.
   • This decision is made outside the MCP protocol and ensures that access control policies can be centrally managed via the OAuth server.
   • Similarly, the client also adheres to the OAuth process independently.

4. Untrusted Environments or Complex N:N Connections:
   When both the MCP server and the client operate in untrusted environments, or when complex many-to-many connections are allowed, both sides must use OAuth with the Authorization Code Flow.

   • This ensures that each party independently obtains credentials via a trusted OAuth server, allowing a robust, user-consented approach to authentication and authorization.

[chgaowei]

Proposal: A W3C DID-Based Solution for Identity Authentication

Currently, most discussions revolve around OAuth-based solutions. While OAuth is functional and standardized enough to leverage existing infrastructure, its overall process is still quite complex.

I would like to propose a completely new solution based on the W3C DID (Decentralized Identifiers) standard. We have been researching and exploring this approach for a long time, primarily to solve identity authentication and encrypted communication challenges between agents. I believe this approach could also be applied to identity authentication between MCP clients and MCP servers.

Why DID?

First, I fully agree that the communication protocols of future AI systems (e.g., MCP) should be open and avoid relying on centralized trust authorities. This aligns perfectly with the W3C DID standard, which advocates for users to have full control over their identity information without depending on centralized authentication entities.

Overview of the DID all Method

We designed a DID method called all (short for "alliance"). Below is a simplified description of how the all method handles identity generation and authentication. For clarity, I'll use a communication scenario between Alice and Bob as an example.

1. Identity Generation

• Key Generation: Alice and Bob each generate an asymmetric key pair (private key and public key). The private key is stored securely by the user.
• DID Creation: A DID is generated by hashing the public key, which serves as the unique identifier. For example:
  did:all:[email protected], where example.com is the DID document server.
• DID Document: A DID document containing the DID and public key is created, signed using the private key, and stored on the web server (example.com). Third parties can retrieve the DID document based on the DID to obtain the corresponding public key.

2. Identity Authentication

• When establishing a connection, Alice sends a connection request containing her DID and a message signed with her private key.
• Bob retrieves Alice’s DID document from example.com using her DID, verifies the signature using the public key in the DID document, and confirms the authenticity of Alice’s DID.
• Similarly, Bob sends a response containing his DID and a signature, which Alice verifies using the same process.
• Once mutual authentication is complete, both parties proceed with encrypted communication.

3. Encrypted Communication

• Since both Alice and Bob have asymmetric key pairs, they can use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) to negotiate an encryption key for end-to-end encrypted communication.

Use Case Examples

File System Access

• The MCP client accesses files stored on the MCP server.
• The MCP server associates files with users’ DIDs.
• When the client requests a file, the server authenticates the client’s DID as described above. If the authentication succeeds, the file or its access token is returned.
• The client can also authenticate the server using its DID or domain name.

Pizza Ordering

• A user orders a pizza via the MCP client, communicating with the pizza store’s MCP server. Assume the user has obtained the store’s DID and URL through a trusted channel.
• The MCP client authenticates the server’s DID to ensure it is communicating with the intended pizza store.
• The MCP server similarly authenticates the client’s DID and records the order for further processing.

Challenges and Opportunities

While DID-based solutions have clear advantages, they also have limitations:

• Adoption: DID is a newly released W3C standard and has not been widely adopted yet. The supporting infrastructure is still developing.
• Potential: Despite these challenges, I believe DID is the most suitable solution for identity authentication between agents.

I hope this proposal sparks interest and discussion. Please consider this approach for your projects.

Related Resources

• W3C DID Specification: https://www.w3.org/TR/did-core/
• DID all Method Design Specification: https://github.com/chgaowei/AgentNetworkProtocol/blob/main/02-did%3Aall%20Method%20Design%20Specification.md
• Agent Network Protocol (protocol designed for communication between agents): https://github.com/chgaowei/AgentNetworkProtocol
• AgentConnect (open-source implementation supporting DID all and end-to-end encryption): https://github.com/chgaowei/AgentConnect

Finally, feel free to reach out to me if you have any questions. I would be more than happy to discuss this topic.

[ggoodman]

I think DID is also a very compelling approach. Some use-cases may benefit from a decentralized auth strategy while others might be simpler if using existing OAuth2 infra.

So to that I would say, why not both?

I think it would be very compelling if the protocol defined an auth discovery mechanism (as discussed in another thread: #64 (reply in thread)). This would allow a layer of indirection and future-proofing to the protocol such that different servers can declare support for different auth strategies. The protocol could encode a set of well-known strategies and the required metadata associated with each type.

[chgaowei]

I think DID is also a very compelling approach. Some use-cases may benefit from a decentralized auth strategy while others might be simpler if using existing OAuth2 infra.

So to that I would say, why not both?

I think it would be very compelling if the protocol defined an auth discovery mechanism (as discussed in another thread: #64 (reply in thread)). This would allow a layer of indirection and future-proofing to the protocol such that different servers can declare support for different auth strategies. The protocol could encode a set of well-known strategies and the required metadata associated with each type.

Adding an authentication discovery mechanism is indeed a very well-thought-out design.
This approach enables a gradual transition from the existing system to the new system.
The MCP server can include the authentication mechanisms it supports in its declaration document. Before connecting, the client can retrieve the declaration document and determine the next steps based on its content.

[jspahrsummers]

I think an initial version would first focus on OAuth2 because that opens the door to connecting to many other services (i.e., MCP servers—or agents—that are simply the "front door" to existing APIs), but I like the idea of making auth broadly pluggable to support things like this.

[chgaowei]

I think an initial version would first focus on OAuth2 because that opens the door to connecting to many other services (i.e., MCP servers—or agents—that are simply the "front door" to existing APIs), but I like the idea of making auth broadly pluggable to support things like this.

I agree with your view. Many servers now have better support for OAuth2, so focusing on OAuth2 for the initial version is indeed a reasonable approach.

I am very much looking forward to the day when authentication can become pluggable. Perhaps connecting to new servers and using new solutions will become more efficient. If possible, I would also like to contribute code to this effort.

Additionally, I have designed a new DID method called "wba," which allows clients and servers to authenticate identities conveniently, similar to how email works. Even though they belong to different platforms, this method facilitates seamless authentication. I’ll create a new post to briefly introduce it. Here is the link:
https://github.com/chgaowei/AgentNetworkProtocol/blob/main/03-did%3Awba%20Method%20Design%20Specification.md

[dschenkelman]

👋 we are Auth0 would love to be part of these MCP + auth conversations

We've been doing some work already to support apps talking to APIs considering the user's permissions, particularly thinking about GenAI apps and how they look to integrate with other apps/APIs: https://demo.auth0.ai/docs/call-apis-on-users-behalf

As @MartinSchlott mentioned, thinking of MCP servers as resource servers should help here. Considering the OAuth covered surface it should be a good place to start with production implementations, learn the gotchas to later implement other approaches (that might or might not be DID related).

[chgaowei]

Proposal: did:wba, a Web-based Decentralized Identifier

1. Introduction

did:wba is a Web-based Decentralized Identifier (DID) specification designed to support cross-platform authentication and agent communication.

The did:wba method leverages existing mature technologies and Web infrastructure to implement decentralized authentication without requiring a complete overhaul of existing systems. Platforms can maintain their centralized account systems while issuing did:wba DIDs to users, enabling interoperability between platforms.

Similar to email, did:wba allows platforms to maintain their centralized account systems while enabling cross-platform communication and interoperability.

2. Cross-Platform Authentication

did:wba can be integrated with HTTP protocol to complete identity authentication, permission verification, and data exchange in a single HTTP request without additional interactions. Below is the interaction flow of did:wba with HTTP protocol:

• Prerequisites: User creates a DID and stores the DID document on Agent A's DID server. The DID is also configured on Agent B's server with appropriate permissions.
• Agent A, as the client, initiates an HTTP request containing the DID and signature along with the request data.
• Agent B, as the server, extracts the DID and signature from the request headers.
• Agent B retrieves the DID document from Agent A's DID server using the DID.
• Agent B verifies the client's signature using the public key from the DID document.
• Upon successful verification, Agent B processes the client's business request and returns both business data and a token.
• Agent A includes the token in subsequent requests, and Agent B authenticates the client by validating the token.

3. Use Cases

1. Use Case 1: User Accessing Files on Other Websites via AI Assistant

Alice has stored a file on example.com and wants to access it through an AI assistant. She first creates a did:wba-based DID on the AI assistant, logs into example.com, associates this DID with her account, and grants file access permissions to the DID. After setup, the AI assistant can log into example.com using this DID, and upon authentication, example.com allows the AI assistant to access Alice's stored files. This DID can be configured on other websites to enable the AI assistant to access files across different platforms.

2. Use Case 2: User Calling Third-Party API Services via AI Assistant

Alice wants to call APIs of a third-party service named "example" through an AI assistant. She first creates a did:wba-based DID on the AI assistant and uses it to subscribe to services on the example platform. The example service authenticates using the DID, confirms Alice as the purchaser, and records her DID. After authentication, Alice can use this DID through the AI assistant to call example service's APIs.

While client-to-server authentication is not detailed in the current use cases, this process is also functional.

4. Code

We are currently under development and expect to complete it next week.

5. References

did:wba Method Specification

DID-CORE

AgentNetworkProtocol Technical White Paper

[jspahrsummers]

@k6l3 has started a concrete proposal here, centered around OAuth. I think it's broadly in line with a lot of the comments in this thread—thank you all for the input and thought here!

[chgaowei]

The PR submitted by k613 regarding authentication (#101) has already defined the framework for extending authentication schemes.

Building on that, we have added the did:wba authentication method as an experimental approach to MCP. The new file can be found here: https://github.com/chgaowei/mcp-specification-didwba/blob/main/docs/specification/revisions/draft/auth/didwba.md.

Once k613's PR is merged, we will submit a new PR. However, before that, we’d like to gather feedback from everyone. Below is some information about did:wba:

We believe did:wba can serve as an excellent complement to OAuth 2.0 for the following reasons:

1. did:wba provides security equivalent to OAuth 2.0.
2. did:wba supports decentralized identity authentication, offering better interoperability.
3. did:wba requires fewer interactions and has a simpler process.

Using did:wba can lower the barrier for users to access MCP servers. Taking API services like exa as an example, if exa also supports did:wba and provides an API subscription interface, users won't need to log in to exa for registration, configuration, and subscription operations. The MCP client can directly use the API and the user's DID to subscribe to exa's services, then send requests with authentication information to exa's MCP server for identity verification and API calls. This makes it much more convenient for users to utilize various MCP servers.

Relevant documentation links:

1. did:wba Method Design Specification

2. blogs：

• did:wba - A Web-based Decentralized Identifier
• Security Principles of did:wba
• The Most Suitable Identity Authentication Technology for Agents: Comparing OpenID Connect, API Keys, and did:wba