Test the two OAuth boundaries in an MCP proxy

An MCP proxy can validate a token correctly but still authorize the wrong business operation. Additionally, it may accept a genuine token that was never meant for the proxy. These are distinct defects that require different testing approaches. This article introduces a small policy fixture for a fictional finance connector, focusing on testing the trust boundaries before integrating the policy into actual authentication middleware.

The fixture does not handle OAuth, verify JWT signatures, or interact with a live MCP SDK. Its primary goal is to make testing the trust boundaries feasible.

To understand the two credential paths, consider the incoming caller as an MCP client requesting invoice information for a user. The connector functions as a resource server during this hop and as a client when it calls the ERP. It is crucial to maintain separate design roles for these two services, even if the same team manages both.

According to the MCP 2026-07-28 authorization specification, the HTTP OAuth flow is necessary to identify the MCP resource and validate the token's intended audience. This is different from the stdio flow. The OAuth 2.1 document, which is still an IETF draft, should be referenced using a specific MCP revision and SDK version rather than claiming "OAuth 2.1 compliance" without context.

Resource indicators indicate the token's destination but do not replace the invoice-level decision made by the application's rules.

The architecture consists of two credential acquisition paths. The incoming credential stops at the MCP resource boundary, while the downstream connector acquires a credential suitable for the ERP through the deployment's approved mechanism. The fixture does not receive raw credentials and cannot select the mechanism for you. A verified context must precede the policy.

In the provided example, the fictional request reads invoice INV-42, owned by business unit north. The authenticated context is obtained from middleware, not the model's arguments. The client consent lookup is sourced from the application's consent store. The following Python policy code demonstrates how to use synthetic inputs to test the policy.

The values named VerifiedContext are assumed to have passed real issuer, integrity, expiry, and resource validation checks before construction. Simply renaming an ordinary dictionary does not make it verified. Avoid exposing a route that allows a caller to populate this structure directly.