Authentication #64

jaredhanson · 2024-11-25T23:34:35Z

jaredhanson
Nov 25, 2024

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 · 2024-11-26T02:44:18Z

at-white
Nov 26, 2024

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!

0 replies

jspahrsummers · 2024-11-26T03:42:29Z

jspahrsummers
Nov 26, 2024
Maintainer

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:

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
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)
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.

1 reply

ggoodman Nov 26, 2024

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

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.
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

The User opens Claude Desktop (the Client) settings and choses to add a remote http MCP Server.
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).
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.
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):

The User visits their MCPaaS dashboard and decides to configure a new integration.
As part of the integration set-up flow, the User must authorize the MCP Server via OAuth2.
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.
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 · 2024-11-26T08:19:57Z

MartinSchlott
Nov 26, 2024

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:

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.
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.
This also means MCP servers don’t need to implement an auth server themselves, which reduces complexity.
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:

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.
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.
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.

1 reply

jspahrsummers Dec 5, 2024
Maintainer

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 · 2024-11-26T08:42:57Z

MartinSchlott
Nov 26, 2024

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

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.
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.
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.
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.

0 replies

chgaowei · 2024-11-26T16:33:47Z

chgaowei
Nov 26, 2024

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:14qQqsnEPZy2wcpRuLy2xeR737ptkE2Www@example.com, 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.

7 replies

jspahrsummers Dec 5, 2024
Maintainer

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 Dec 5, 2024

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

vdods Mar 11, 2025

I'm a fan of using DIDs for MCP authentication, and would suggest allowing multiple DID methods to be used in principle.

One reason for allowing different DID methods is because of the different cryptographic verifiability guarantees they can provide. For example, did:web (and did:wba, if I'm understanding it correctly) are both appropriate for DNS-based retrieval of the current public keys of the DID controller (DID controller being the term used for the entity that controls the private keys for the DID). These DID methods are relatively straightforward to implement and support.

There are several potential successors to did:web in the works that add additional layers of strength, such as a cryptographically verifiable history, DID alteration/forking prevention, and long-term DID resolution guarantees. I have my own horse in that race (https://github.com/LedgerDomain/did-webplus), and there are two others (https://github.com/decentralized-identity/didwebvh and https://trustoverip.github.io/tswg-did-method-webs-specification/).

The reason I bring this up is that did:webplus was made specifically so that its DID documents (the public key material) is historically auditable (in my industry, this can be up to 12 years of history). If MCP-enabled agents are used in a setting where their activity might be subject to audit, and this could certainly include authentication of the agent itself. Not all use cases will need this, but some will.

chgaowei Mar 11, 2025

We also strongly agree with the DID approach and have adopted DIDs for identity verification in ANP (Agent Network Protocol).

https://github.com/agent-network-protocol/AgentNetworkProtocol

bumblefudge Mar 27, 2025

Just chiming in here to say that DID systems are an interesting and diverse set of identity architectures that could definitely be powerful here, many of which have security, confidentiality, and auditability properties useful to these kinds of open-world/decentralized contexts. I came to point out that just as OAuth is a no-brainer for hierarchical/enterprise systems anchored in domain-based identity and reputation systems (bound as they are to .well-known mechanisms and DNS), a more decentralized or ICANN-free identity system (whether it uses DID as its export format and/or native identifier scheme) needs a decentralized and ICANN-free equivalent at the Authorization level. Lots of W3C/RDF-based systems that use DIDs use "ZCaps" for this (a kind of authorization-specific variant of Verifiable Credentials that come with an AuthZ DSL designed with API endpoints in mind); some more web3/dweb-type projects, many of which also use DIDs, use UCANs, a less RDF-/Linked-Data-friendly CBOR token language for their own object-capabilities system. In an extremely local-only/offline agentic context, something like Keyhive might even be useful, which is similar to UCANs and by the same protocol designer but optimized for local-first and eventual-consistency/postfacto-auditing. All three of these share an "object capabilities" approach that avoids the requirement of a constantly-available central server visible to all parties (at least for delegation events), all avoid the requirement of internet connectivity for all parties at all times, and all support rich vocabularies for attenuated delegation and notarization, putting them closer to macaroons and to other novel authorization systems than to OAuth in their properties.

I mention all of this to say that if DIDs seem slightly off-topic here, it's because DIDs are like URI schemes defining the properties of a given decentralized identity system. Few DID method specifications treat Authorization centrally (much less auditable, headless authorization!), and reading through a few DID method specifications can be a little underwhelming if you're evaluating them primarily on their relative applicability to agentic authZ/authN usecases that are MCP's focus. These DID method specifications often punt on AuthZ considerations either to a very specific OAuth profile that they mandate (in the case of domain-based systems) or to some experimental/young OAuth replacement like GNAP or those object-capabilities systems mentioned above.

More generally, though, it seems like this discussion is "closed" now that the Auth section has been added to the working draft. Is there another discussion thread (or could we start one) where interested parties can discuss the usage of DIDs with (or beyond!) OAuth? The reference to "alternative transports" is enticing, as a researcher who works with the IPFS Foundation, so if there is interest in DePIN, edge-AI, or alternate-transport applications of MCP I would love to be tracking those and can at least volunteer bibliography and context if people there have questions about any of the technologies mentioned above.

dschenkelman · 2024-11-29T19:21:58Z

dschenkelman
Nov 29, 2024

👋 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).

0 replies

chgaowei · 2024-12-05T14:55:38Z

chgaowei
Dec 5, 2024

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

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.

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

1 reply

zzzming May 29, 2025

I think tooling, docs, maturity of libraries, and infrastructure (i.e. key management) complexity are frictions for DID adoption in the past. There are a lot of investment collectively gone into oauth/2 that cannot be undermined. I have to say decentralization is a good point.

jspahrsummers · 2024-12-06T13:35:23Z

jspahrsummers
Dec 6, 2024
Maintainer

@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!

0 replies

chgaowei · 2024-12-25T15:30:01Z

chgaowei
Dec 25, 2024

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:

did:wba provides security equivalent to OAuth 2.0.
did:wba supports decentralized identity authentication, offering better interoperability.
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:

did:wba Method Design Specification
blogs：

0 replies

whitlockjc · 2025-01-31T17:47:27Z

whitlockjc
Jan 31, 2025

Would there be any benefit to using prior art (AsyncAPI, OpenAPI, ...) for describing the authentication/authorization requirements between components? There was also a prop for OpenAPI (moved to a future OpenAPI version) that might make this a bit easier to wire up and futureproof for supporting other ways to specify credential locations/custom security schemes/...: OAI/OpenAPI-Specification/pull/2582

0 replies

ognis1205 · 2025-02-03T13:26:20Z

ognis1205
Feb 3, 2025

Following.

0 replies

jspahrsummers · 2025-02-05T10:53:25Z

jspahrsummers
Feb 5, 2025
Maintainer

Auth is part of the draft version of the spec now!

4 replies

Zawad Mar 26, 2025

Was this intentionally taken down?

pontuspalmenas Mar 27, 2025

@Zawad It's here now: https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/authorization/

tedpower Mar 31, 2025

Love it! I know this is hot of the presses, but is there any guess as to when there might be e.g. a beta of the Claude desktop app (or equiv.) that implements the 2025-03-26 spec, such that we can test the oauth hand-off flow end-to-end?

geelen Apr 1, 2025

You can use the inspector to test, or I built https://www.npmjs.com/package/mcp-remote to use with clients like Claude Desktop today, or https://playground.ai.cloudflare.com/ is now an MCP client that supports auth too.

mtmcp · 2025-02-05T22:51:40Z

mtmcp
Feb 5, 2025

Nice I like the idea of using OAuth. Seems like taking it a step further and adopting OpenID connect might make sense too, along with JSON web tokens. This would be perfect for access control on the various APIs.

And then GitHub actions could run LLMs and call functions on one's behalf! 😊

2 replies

jspahrsummers Feb 13, 2025
Maintainer

If you have a specific idea for how to integrate OIDC here, it might be interesting to hear—perhaps in a proposal PR? I'm not totally sure I see the use case for it yet.

mtmcp Feb 21, 2025

@jspahrsummers Apologies for the delayed response. I will give it more thought on the particulars as I work with MCP, but the main benefit which comes to mind is to standardize access control to the resources, prompts, et cetera. By using OpenID connect, servers could unify on a particular Json Web Token claims-structure, allowing client code to be able to operate more seamlessly.

Otherwise, every MCP server might support the same authentication methodology, but after authenticating there's no standardized access control mechanism. I realize it will add quite some complexity to consider access control in a general sense, but something to consider at least.

adamsiwiec1 · 2025-03-05T04:34:40Z

adamsiwiec1
Mar 5, 2025

If you have been brought to this issue from the docs simply looking for a solution to securely share a publicly hosted custom MCP SSE deployment with your team (as I was earlier), your immediate answer as of right now is a proxy of some sort of proxy/network layer based solution. Basic auth, api keys, forget about it. Depending on how large your team is in conjunction with how sensitive your data is, a simple proxy may not be an ideal solution.

I created a more secure proxy solution that allows users to authenticate to an MCP server securely via IAM, utilizing the Google Cloud SDK and Cloud Run request IAM authorization.

https://github.com/the-freetech-company/mcp-sse-authenticated-cloud-run/tree/master

GCP Cloud Run Proxy Script

Any feedback is welcome, I stumbled upon this idea earlier today.

0 replies

dasiths · 2025-03-16T08:32:30Z

dasiths
Mar 16, 2025

Thank you for starting the thread. Just wanted to know if oauth token exchange flow was ever discussed? https://oauth.net/2/token-exchange/.

i.e. This is an example implementation in Azure EntraID

I believe the comment from @dschenkelman is on the same lines.

You can consider an MCP server as a middle tier resource server, exchanging the incoming token for another token to access downstream services. This would allow an MCP server wrapping an HTTP API to consume the API on behalf of the user. It also allows for easy interoperability with current authn/authz designs as well. Encouraging this design would also decrease the blast radius of "LLM Tool use" for enumeration based attacks as the calls from the MCP server to downstream services will have a "user context" attached which would allow the downstream service to sandbox the operations to that attached "user context".

2 replies

bdoyle0182 Mar 24, 2025

I think this is critical functionality that the authorization to the third party integration api by the mcp server needs to be easily forward or exchange a token for identity tracing purposes for a widely used remote server.

raykao Apr 2, 2025

+1 Would be great if this could be added as the MCP client side spec to be able to handle some of this or at least know how to kick off an oauth flow.

The proxy model by @adamsiwiec1 is a good work around in-lieu of a solution today, but only if the provider of the proxy is "trusted".

To me the issue regardless of proxy or MCP Client being Oauth (or other auth) aware is that any "MCP middleware" could be able to take the identity from another service - as currently it runs as a child proc of the client if i'm not mistaken.

Essentially we've recreated XSS/X-Site-Leaks in browsers and now into MCP Client. The MCP client should create/implement some kind of security boundary to protect identity being stolen and sent to any remote SSE/HTTP MCP server configured.

ground-creative · 2025-04-15T10:32:25Z

ground-creative
Apr 15, 2025

Authentication is definitely a key topic.

I've created a lightweight ASGI container for the MCP using FastAPI. It includes middleware that handles authentication by checking each incoming request.

With this setup, it's also possible to verify user authentication directly within the tools themselves.

You can check it out here:
🔗 https://github.com/ground-creative/easy-mcp-python

There are also a few example implementations linked in the repository.

0 replies

adamsiwiec1 · 2025-04-15T16:19:59Z

adamsiwiec1
Apr 15, 2025

@ground-creative How would we pass an auth token, api key, or some form of claims (to be used in the middleware) for SSE connections in clients such as Cursor with this solution?

3 replies

ground-creative Apr 15, 2025

Just need to set your variables in the middleware and retrieve them from within the tools.

# app/middleware/MyMiddleware.py

from starlette.middleware.base import BaseHTTPMiddleware
from fastapi import Request
from mcp.server.fastmcp import Context      # Use `ctx: Context` as function param to get mcp context
from core.utils.logger import logger        # Use to add logging capabilities
from core.utils.state import global_state   # Use to add and read global vars

class MyMiddleware(BaseHTTPMiddleware):
    def __init__(
        self, app, *args, **kwargs
    ):
        super().__init__(app)

    async def dispatch(self, request: Request, call_next):

         global_state.set("middleware.MyMiddleware.is_authenticated", False, True)

         # We are looking for paramters in the request headers
         access_token = request.headers.get("x-access-token", None)

         if not access_token:
                global_state.set( "middleware.MyMiddleware.error_message", "Some error msg.", True,)

         global_state.set("middleware.MyMiddleware.is_authenticated", True, True)
         global_state.set("middleware.MyMiddleware.some_data", {"some_key":"some value"}, True)

         response = await call_next(request)
         return response

From within a tool a this point:

# app/tools/add.py

from mcp.server.fastmcp import Context      # Use `ctx: Context` as function param to get mcp context
from core.utils.state import global_state   # Use to add and read global vars
from core.utils.logger import logger        # Use to import the logger instance

def add_numbers_tool(a: int, b: int) -> int:
    """Add two numbers"""

   is_authenticated = global_state.get("middleware.MyMiddleware.is_authenticated")

   if not is_authenticated:
         return {"error":"not authenticated"}

    return a + b

And we can send our authentication parameters via headers.

Here is an example middleware

https://github.com/ground-creative/easy-mcp-google-auth-middleware/blob/main/GoogleAuthMiddleware.py

adamsiwiec1 Apr 15, 2025

This unfortunately will not work for SSE connections in IDEs like Cursor at the moment, because you cannot pass headers

ground-creative Apr 15, 2025

You might be able to use this as a workaround:

https://github.com/sparfenyuk/mcp-proxy

You might have success with a proxy stdio -> sse style.

benjaminbelaga · 2025-12-25T23:23:51Z

benjaminbelaga
Dec 25, 2025

Sharing my production experience with Google OAuth in a remote MCP server.

My Setup

I run an MCP server for Google Workspace (Gmail + Calendar) on a VPS, connecting via Claude Code CLI. Here's how I handle auth:

Token Lifecycle

User authenticates via Google OAuth consent screen (one-time)
Server stores refresh_token + access_token in ~/.google_workspace_mcp/credentials/
On each request: check access_token expiry → refresh if needed
Google refresh_tokens last ~6 months (or until revoked)

Key Implementation Details

Token storage:

# Tokens persisted per-user with proper file permissions (600)
credentials_path = Path.home() / ".google_workspace_mcp" / "credentials"

Auto-refresh pattern:
if credentials.expired and credentials.refresh_token:
    credentials.refresh(Request())
    save_credentials(credentials)  # Persist new access_token

Security Considerations

1. Never log tokens - even in debug mode
2. File permissions matter - 600 for credential files
3. Separate auth server - I use the MCP server itself for OAuth endpoints, but architecturally they're distinct routes

What Works Well

- Google's OAuth libraries handle most complexity
- Refresh tokens are long-lived enough for daily use
- Systemd restarts preserve auth state (tokens on disk)

Pain Points

- Initial OAuth consent requires browser redirect (can't be fully headless)
- Token revocation by user requires re-auth flow
- Multi-user support needs per-user credential isolation

Happy to share more details. Repo: github.com/benjaminbelaga/mcp-google-workspace

0 replies

dreynow · 2026-03-15T14:45:47Z

dreynow
Mar 15, 2026

The OAuth spec covers human-to-server auth well. But there is a gap for agent-to-agent delegation - when Agent A delegates a task to Agent B, and Agent B calls an MCP tool, the server has no standard way to verify:

Which agent is calling (not the human - the specific agent instance)
What it is authorized to do (which tools, cost limits, resource constraints)
Who granted that authority (the delegation chain back to a root)

This is especially relevant for the stdio transport, where the auth spec explicitly says to "retrieve credentials from the environment" - meaning no per-call authorization.

We built and open-sourced a library that adds cryptographic delegation proofs to MCP tool calls. It works on all transports (stdio, HTTP, SSE) because the proof is self-contained in the tool arguments.

The approach:

Agents carry Ed25519 keypairs and did:agent: identifiers
Authority flows through signed delegation chains with caveats (action scope, expiry, cost limits, resource patterns)
Each tool call carries a _proof with the full chain - servers verify locally, no external lookups
Complements OAuth (OAuth = human authorizes client, delegation = agent proves authority)

Available in Rust, TypeScript, and Python (MIT):
github.com/kanoniv/agent-auth

Full spec proposal for adding an auth field to MCP tool calls: #2404

3 replies

dasiths Mar 15, 2026

Just FYI this is an old thread that resulted in the PRM and CIMD being introduced to the MCP Auth spec.

RE: OAuth for delegation. You can build on top of RFC 8693. A good example is Entra Agent ID. https://blog.christianposta.com/entra-agent-id-agw/PART-1.html

dreynow Mar 15, 2026

Good call on RFC 8693 - thanks for the pointer. Looked at Entra Agent ID as well.

The key difference is the transport assumption. RFC 8693 and Entra both require an authorization server for token exchange. That works well for HTTP-based MCP servers where you have a network path to the auth server.

But for stdio transport (how Claude Code, Cursor, and most local MCP servers connect), there is no auth server to call. The current MCP auth spec explicitly says stdio should "retrieve credentials from the environment" - meaning no per-call authorization at all.

Self-contained delegation proofs solve this because verification is local. The proof carries the full chain, every signature is checked in-process, no network call needed. That is the specific gap this targets.

They could complement each other well:

HTTP transport: RFC 8693 / Entra for enterprise environments with existing IdPs
stdio transport: delegation proofs for local agent-to-agent auth
Both: a gateway (per Spec Proposal: A Gateway-Based Authorization Model #804) could mint delegation proofs from its policy engine, giving you centralized policy + decentralized verification

The full proposal with more detail: #2404

dasiths Mar 18, 2026

Seeing a lot of overlap with agent-auth spec by Dick Hardt here: https://github.com/christian-posta/aauth-full-demo/blob/main/SPEC.md

Are they related?

It's also worth noting that there is an effort underway to standardize the act claim. https://notes.karlmcguinness.com/notes/standardize-act-across-assertion-grants-and-jwt-access-tokens/

dreynow · 2026-03-18T19:49:53Z

dreynow
Mar 18, 2026

Thanks for the pointers - looked at both.

The core principle we're building around: verification should be self-contained, not dependent on infrastructure. A delegation proof should be verifiable by any party, on any transport, without calling an authorization server.

Ed25519 delegation chains achieve this. The proof carries the full authority chain - who delegated what to whom, with what constraints, signed at each hop. Verification is local, works on stdio, HTTP, SSE, or any future transport. No network round-trip, no token exchange endpoint, no dependency on a running auth server.

JWT act claims and RFC 8693 are solid for enterprise environments where you already have an IdP in the loop. The act claim captures delegation identity (who is acting for whom) but not delegation authority (what they're allowed to do, with what constraints). Scoped delegation chains carry both.

AAuth is a more comprehensive rethinking of OAuth, but it requires HTTPS endpoints, JWKS discovery, and agent/auth/resource servers in the loop. That works for HTTP transports - but local agent pipelines (CrewAI, LangGraph, Claude Code over stdio) have no auth server to call. The current MCP spec acknowledges this gap explicitly for stdio.

@kanoniv/agent-auth implements self-contained delegation proofs. The approaches compose well:

Authentication #64

Uh oh!

Replies: 24 comments · 24 replies

Uh oh!

Uh oh!

Uh oh!

jspahrsummers Nov 26, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jspahrsummers Dec 5, 2024 Maintainer

Uh oh!

Uh oh!

Proposal: A W3C DID-Based Solution for Identity Authentication

Why DID?

Overview of the DID all Method

1. Identity Generation

2. Identity Authentication

3. Encrypted Communication

Use Case Examples

File System Access

Pizza Ordering

Challenges and Opportunities

Related Resources

Uh oh!

jspahrsummers Dec 5, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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

1. Introduction

2. Cross-Platform Authentication

3. Use Cases

4. Code

5. References

Uh oh!

Uh oh!

Uh oh!

jspahrsummers Dec 6, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jspahrsummers Feb 5, 2025 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 24 comments 24 replies

jspahrsummers
Nov 26, 2024
Maintainer

jspahrsummers Dec 5, 2024
Maintainer

jspahrsummers Dec 5, 2024
Maintainer

jspahrsummers
Dec 6, 2024
Maintainer

jspahrsummers
Feb 5, 2025
Maintainer