Guidance on handling per-user credentials for a remote MCP server acting as a proxy to multiple APIs

[kaheidt]

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

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:

1. Does the MCP spec intend to define a standard for handling per-user credentials when the MCP server acts as a proxy?
2. Is passing credentials via custom headers acceptable under the spec, or is this considered a security anti-pattern?
3. 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.

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?

[Theaxiom]

This is covered in the scope of my SMCP RFC: https://github.com/orgs/modelcontextprotocol/discussions/689

[isheng-eqi]

You have hit one of the hardest unsolved problems in MCP server design. Here is where the spec stands and what patterns work in practice today.

Where the spec stands

The MCP spec does not currently define a standard for per-user credentials in proxy scenarios. This is a known gap. The spec defines OAuth 2.0 for server-to-client authorization (the client authenticates to the server), but not for server-to-upstream-API credential propagation (the server authenticating as the user to GitHub/Slack/etc.).

You are correct that the OAuth On-Behalf-Of (OBO) flow would be the ideal solution but is blocked by the lack of trusted relationships between identity providers. This is not an MCP problem — it is a fundamental federated identity problem that the industry has been working on for decades (SAML, SCIM, etc.).

Your three questions, answered

1. Will the spec define a standard for this?

The closest thing in progress is SEP-1036: URL Mode Elicitation (PR #887), which you already found. It allows the server to ask the client to open a browser URL where the user can complete an out-of-band interaction (like entering API keys). This is the "secure storage alternative" you mentioned — and yes, your read is accurate.

There is also SEP for Authorization being discussed that covers resource-level access control. But a full "multi-tenant proxy credential" standard is not yet on the roadmap as a formal SEP.

2. Is passing credentials via custom headers acceptable?

It works, but it is a security anti-pattern in the general case.

The concern is the "confused deputy" problem: if the MCP client blindly forwards user credentials in headers, a malicious or compromised MCP server could exfiltrate them. The spec's guidance against passing OAuth tokens through is based on this risk.

However, in an enterprise deployment where:

• You control both the client and server
• The connection uses TLS with mutual authentication
• The custom headers are stripped after the server maps them to an internal session

...this pattern is pragmatic and widely used. Many production MCP deployments pass X-User-Id or X-Tenant-Id headers. The key safeguard: never pass raw upstream API keys as headers. Instead, pass an opaque session token that the server resolves to stored credentials server-side.

3. Recommended patterns for multi-user proxy servers

Here is what works in production today, from simplest to most robust:

Pattern A: Session-based credential mapping (simplest)

1. User authenticates to MCP server via OAuth (standard MCP auth)
2. Server issues a session token
3. User configures upstream API keys via an out-of-band admin UI or tool call
4. Server stores {session → {github_key, slack_key, ...}} in a secure vault
5. On each tool call, server looks up credentials by session

Pros: clean, no custom headers needed. Cons: requires credential storage infrastructure.

Pattern B: Header-based identity forwarding (pragmatic)

1. Client passes X-User-Identity header with each request
2. Server maps identity → stored credentials (populated out-of-band)
3. Credentials never leave the server

This is what most enterprise deployments do today. The X-User-Identity is typically a JWT or opaque token, not a raw API key.

Pattern C: Elicitation-based credential collection (spec-aligned future)

1. Server calls elicitation → client opens browser → user enters API key
2. Server stores the key securely, associated with the session
3. Subsequent tool calls use the stored credential

This is the SEP-1036 approach and will be the "correct" spec-aligned answer once merged.

Concrete recommendation for your transition

For moving from local STDIO to remote service:

1. Short term: Use Pattern B (header-based identity). Pass an opaque internal user token via a custom header. The MCP client adds it (or it is injected by an auth proxy in front of your server). Map it to stored credentials server-side.

2. Medium term: Implement Pattern A by adding a credential management API (could be an MCP tool like configure_integration(service="github", api_key="...") that stores keys server-side).

3. Long term: Adopt SEP-1036 elicitation when it lands, replacing the custom credential tool with a standardized elicitation flow.

One critical security note

Whatever pattern you choose, never log upstream credentials. Your MCP server will handle API keys for multiple users — a logging mistake that leaks one user's GitHub token to another user's log output is catastrophic. Use structured logging with automatic credential redaction from day one.