MCP Proxy OAuth Trust Boundaries: Consent and Redirect URIs per Client

An MCP proxy can accept many dynamically registered clients while using one static OAuth client ID at a third-party API. That arrangement compresses two client identities into one. A consent cookie at the upstream authorization server records approval for the proxy's static client ID; it does not prove approval for every newly registered MCP client behind the proxy. If the proxy forwards a new client's authorization request without its own per-client consent, earlier upstream approval can be reused as though it covered the new client. That is the confused-deputy trust boundary described by the MCP security guidance.

Where client identities collapse

The third-party authorization server cannot see how many MCP clients exist inside the proxy. A provider consent screen displayed once does not prove that a user approved a later MCP client. The proxy becomes a deputy when it mistakes approval of its static identity for approval of the downstream party asking it to act.

Protections required by current MCP guidance

The MCP 2026-07-28 Authorization Security Considerations require a proxy using a static upstream client ID to obtain user consent for each dynamically registered client before forwarding to the third-party authorization server. The official Security Best Practices further require the MCP-level consent screen to identify the requesting client, show the requested third-party scopes, and show the registered redirect_uri. The proxy must retain approved client IDs per user rather than a single “user already consented” flag.

The authorization request's redirect_uri must exactly match its registered value. Wildcards and pattern matching do not preserve the boundary; a changed URI requires registration again. The proxy must create and store a transaction-specific state only after consent, validate it at the callback, and make it single-use. These controls belong to the proxy even if the upstream provider maintains its own consent cookie.

The current Authorization specification prioritizes pre-registration for existing relationships and Client ID Metadata Documents for clients without one. Dynamic Client Registration remains a supported fallback when the authorization server advertises it. DCR is not itself evidence of a vulnerability. The dangerous combination is dynamic downstream identity, a shared static upstream identity, and no consent boundary between them.

Evidence for an adoption decision

An adopter should verify what identity the consent record actually binds. The following evidence set is an MCP Guard operational recommendation rather than a protocol-defined storage format:

• consent bound to user, MCP client_id, registered redirect URI, and requested scopes;
• negative tests rejecting an unapproved client, a changed redirect URI, and reused state before upstream forwarding;
• audit mapping between the upstream static client ID and each downstream MCP client identity; and
• callback correlation proving that the authorization request, consent, state, client, and final redirect belong to one transaction.

Adoption is supportable when every downstream client receives consent before upstream forwarding, redirect URIs match exactly, and callback state resolves to the originating client. Require remediation before connection when the proxy relies only on a provider's previous consent for its static client ID.

Scope and sources

This design analysis uses the stable MCP 2026-07-28 Authorization specification, its normative Security Considerations, and official Security Best Practices reviewed on September 22, 2026. It does not report exploitation of a particular proxy or claim a product CVE. The table and adoption evidence are MCP Guard recommendations derived from the public requirements.

• MCP 2026-07-28 Authorization: client registration approaches
• MCP 2026-07-28 Authorization Security Considerations: Confused Deputy
• Official MCP Security Best Practices: Confused Deputy Problem