Remote MCP multi-user authentication: token audiences, delegation and proxy consent

The July 2025 discussion begins with a developer's practical question: how to let multiple users authenticate to a single remote MCP server. Their proposed solution was straightforward—build OAuth on the client side, pass the bearer token to the remote MCP server, and have the server itself pass that bearer token in each individual tool call. The questioner noted they planned to use LibreChat as the client (which handles per-user OAuth tokens and automatically passes them in the HTTP request to the server) and on the server side would not store any credentials but just automatically extract that bearer token from the http call and input it into the tool call.

The supplied 2026-07-28 security document defines token passthrough as accepting a client token without validating that it was issued for the MCP server, then passing it to a downstream API. The defect is the missing audience check: a credential intended for one resource is treated as authorization at another. This gives the reader a precise way to assess the proposed shortcut—trace the token’s intended recipient and the validation performed before each use.

The authorization document’s Token Handling requirements reinforce the boundary around tokens issued for the MCP server. The proposal should therefore be evaluated at the validation and delegation steps, rather than by whether the server stores credentials. The analysis uses the 2026-07-28 text; the July 2025 answer already referred to token passthrough as an anti-pattern.

The first boundary is the intended recipient of the incoming access token. In the supported HTTP authorization mechanism, the MCP server validates that the token is intended for this MCP resource, and the client identifies that resource through RFC 8707 resource indicators. The check is about the token’s intended audience, with its concrete validation depending on the token format and authorization setup. The proxy-consent controls below have a narrower scope: the guide’s scenario combining a static third-party client ID, dynamic MCP client registration and a third-party consent cookie.

The second boundary is per-client consent enforced before third-party authorization. The security best practices page requires that MCP proxy servers MUST maintain a registry of approved client_id values per user and check this registry before initiating the third-party authorization flow. This prevents the confused deputy attack, where a static client ID combined with dynamic client registration and a consent cookie allows an attacker to obtain authorization codes without proper user consent by crafting a malicious link that exploits the browser's existing consent state.

The third boundary separates access to the MCP server from authorization at a downstream API. The documents prohibit accepting or transiting tokens not issued for the MCP server and describe unvalidated passthrough as an anti-pattern. An implementation review should therefore trace two decisions: why the MCP server accepts the incoming credential, and which credential or delegation authorizes the downstream API call. Backend credentials need their own intended target and authorization path.

On the client side, the required resource parameter in authorization and token requests identifies the target MCP server. On the server side, token validation checks that intended target. These are complementary controls at different points in the same path. A useful implementation review follows the request through token issuance to validation, rather than stopping at the fact that an OAuth login succeeded.

For the proxy scenario described in the confused-deputy mitigation, the guide calls for approved client_id values per user, checked before the third-party authorization flow, with consent decisions stored securely. Its consent screen requirements cover the requesting client, requested third-party scopes, registered redirect URI, CSRF protection and framing protection. The implementation task is to enforce that user–client approval relationship at the specified point in the flow; the storage architecture can be evaluated against those requirements.

Third, if cookies track consent decisions, they MUST use the __Host- prefix (which prevents parent-domain or path-based cookie setting), set Secure, HttpOnly, and SameSite=Lax attributes, be cryptographically signed or backed by server-side sessions, and bind to the specific client_id rather than a generic user-has-consented flag. Fourth, the MCP proxy server MUST validate that the redirect_uri in authorization requests exactly matches the registered URI, using exact string matching rather than pattern matching or wildcards, and reject requests if the redirect_uri has changed without re-registration.

The guide’s OAuth-state requirements concern generation, storage and checking of state in the proxy consent flow, including the ordering of consent approval and state tracking. State handling belongs beside redirect-URI validation and client-specific consent in the review. Incoming-token validation is a separate check: it establishes that the credential was issued for the MCP server. Keeping those responsibilities separate makes the design inspectable.

Credential storage and authorization-decision storage solve different problems. A consent registry records approved client IDs and user relationships; third-party secrets are a separate category. Where consent cookies are used, the guide specifies cookie protections and signed cookies or server-side sessions. An implementation review can therefore ask for the client-specific consent record and its protection independently of where API credentials reside.

The authorization document makes authorization optional and describes this mechanism for HTTP-based transports. It directs STDIO implementations to obtain credentials from the environment instead. The confused-deputy mitigation applies to its specified proxy arrangement. These scope distinctions determine which checks to apply: identify the transport and credential scheme, then evaluate the relevant controls.

The questioner’s proposed LibreChat-side setup already receives per-user OAuth tokens and proposes server-side forwarding. That establishes the client-side starting point; the next implementation questions are the MCP server’s audience validation and the downstream API’s authorization path. The participant also describes an Apify API-key approach. Its credential target and user binding need to be examined as an API-key design before OAuth-specific requirements can be applied.

The questioner later links an OAuth example and says it fixes the confused-deputy problem. That claim identifies a candidate to inspect. The concrete review would look for resource parameters, incoming-token audience validation and the client-approval controls applicable to its proxy design. In this study, the source is the forum description; implementation code was not inspected.

The selected answer in July 2025 acknowledges uncertainty and already refers to token passthrough as an anti-pattern. The discussion was later closed under the repository’s discussion policy. This chronology places the proposed shortcut in an existing security debate, while the dated specification supplies the requirements used for the present comparison.

The useful output is a requirements-to-evidence map. The forum supplies three described approaches, and the current documents supply the relevant boundaries. For a concrete implementation, obtain the missing request, validation and consent evidence in the matrix. This lets a buyer or developer compare actual code and configuration using the same questions, instead of choosing by an OAuth label alone.

For a remote HTTP MCP service using this authorization mechanism, acceptance should turn on two visible paths: an incoming token intended for and validated by the MCP server, and a separately justified downstream API authorization. If the service uses the guide’s proxy arrangement, add the per-user client approval and related redirect, cookie and state controls. This is the stronger design basis supported by the documents because it addresses the distinct authorization decisions hidden by simple bearer forwarding.

Before choosing or shipping an implementation, request the resource parameter, the audience-validation decision, the user-to-downstream authorization binding and, where applicable, the proxy consent record. These are proposed evaluation steps, not tests performed in this study. The supplied materials do not certify a reference implementation, establish current product vulnerabilities or quantify an operational-cost difference.