You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
We currently run an enterprise MCP server that exposes tools for multiple APIs (GitHub, Slack, Rally, New Relic, PagerDuty, etc.). Today, each user launches the MCP server locally via STDIO, supplying their user-specific API keys as environment variables at startup.
We’d like to transition to offering this MCP server as a remote service (following our standard deployment lifecycle), so users don’t need to maintain local versions to benefit from updates. The challenge:
Each upstream API requires user-specific credentials (API keys or OAuth tokens).
If the upstream API supports OAuth, use of OAuth On-Behalf-Of (OBO) token exchange (RFC 8693) is not feasible since there isn't a means of establishing a trusted relationship between the two identity providers
The MCP spec discourages passing OAuth tokens through to avoid the confused deputy problem, but it doesn’t seem to explicitly forbid passing credentials via custom headers for mapping to the correct upstream identity.
Alternatively, we could implement secure storage for per-user credentials, populated via an explicit tool call or an out-of-band process.
Questions:
Does the MCP spec intend to define a standard for handling per-user credentials when the MCP server acts as a proxy?
Is passing credentials via custom headers acceptable under the spec, or is this considered a security anti-pattern?
Are there recommended patterns for multi-user remote MCP servers that need to maintain user context for upstream API calls?
In my opinion, the spec could benefit from guidance on multi-user scenarios and how an MCP server should behave as a proxy in a way that preserves user context securely.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Question Category
Your Question
We currently run an enterprise MCP server that exposes tools for multiple APIs (GitHub, Slack, Rally, New Relic, PagerDuty, etc.). Today, each user launches the MCP server locally via STDIO, supplying their user-specific API keys as environment variables at startup.
We’d like to transition to offering this MCP server as a remote service (following our standard deployment lifecycle), so users don’t need to maintain local versions to benefit from updates. The challenge:
Questions:
In my opinion, the spec could benefit from guidance on multi-user scenarios and how an MCP server should behave as a proxy in a way that preserves user context securely.
EDIT
I did a little more digging and landed at Proposal: Fine-Grained Resource Control for Multi-User Authorization which seemed somewhat related, but that lead me to PR 475, which then lead to open PR 887: SEP-1036: URL Mode Elicitation for secure out-of-band interactions. It looks like the solution is to essentially use elicitations to have the client open a browser that allows the user to enter a key into some, essentially doing the secure storage alternative I mentioned above. Is that accurate?
Beta Was this translation helpful? Give feedback.
All reactions