Best Practices for remote MCP bearer token Authentication

[henrycashe26]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Hi Everyone,

Is there a best practice for setting up authentication for multiple users to a remote MCP server?

For example, it seems the only working workflow is to build OAuth on the client side pass the bearer token to the remote MCP server and then have the server itself pass the bearer token in each individual tool call. This way we can have multiple users safely access their version of whatever service the remote MCP server is built for.

It doesn't seem like their is much information or documentation on different implementations of this on the internet and in all honesty I can't think of another way to setup multiple user authentication for remote MCP servers.

I was able to find this server side FastMCP implementation for OpenWebUI on their discussion board - here's the code connected to the PR for it.

On my side I'm planning on setting up a similar system using LibreChat at the client (handles per user OAuth token and automatically passes them in the http request to server) and then on my server side I'm not going to store any credentials but just automatically extract that bearer token from the http call and input it into the tool call. Does anyone foresee any problems with this setup?

[yannj-fr]

I think the underlying question is the role of the MCP server. If the MCP server acts as an adapter to the service the user is directly accessing, it looks like using the user bearer token to authenticate to the service helps to keep a consistent experience, but implementation has to be done accordingly to best practices in this page : https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices.

Example :

Token Passthrough
“Token passthrough” is an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued to the MCP server and “passing them through” to the downstream API.

Actually I am really questioning the right approach, which is not totally clear.
My understanding is that you are supposed in the MCP Server to be registered to the final API as an application :

• possibly with a single Client ID for each MCP Client-
• complete an Oauth flow so the final user will give its consent for the MCP server to be used and verifying strictly that the token was issued for you application UUID.

On the opposite if the MCP server is providing a specific service that is not directly accessible to the user, (which is often the case in corporate implementation), it looks like the MCP server would implement a different logic between MCP Client <> MCP Server and MCP Server <> API (may be a client secret), which is not really documented, but might worth to be discussed.

[henrycashe26]

The confused deputy problem forces you to setup your own validation inside of the mcp server, and there doesn't seem to be a known implementation or best practice for how to validate these tokens to the correct client which seems like something the community should outline for future devs -> I went down the rabbit hole and I found this open source implementation by Apify but instead of using OAuth they directly allow users to pass in API keys with the header request. I think this implementation makes sense a dirty fix as if you don't store the api key anywhere inside of the mcp server where each request to the server includes the api to use and is directly passed into the tool call instead of saving it anywhere locally you should have a stateless system? But this entirely skips OAuth usage and creates vulnerability that you have to trust the user who passed the cred is actually the right user which should be implied by them having access to their private api key but still not a great solution.

[henrycashe26]

I've been trying to search for more open source implementations of how people have figured out client validation on the mcp server, but I'm having trouble finding one - anyone know any open source implementations of OAuth mcp servers that properly handle validating client tokens? UPDATE: Example OAuth usage - fixes the confused deputy problem