Connector Namespace MCP server returns 403 to Foundry OAuth passthrough (Runtime.All vs user_impersonation scope)

[lilyjma]

Summary

A Foundry agent using OAuth Identity Passthrough authenticates successfully and reaches a Connector Namespace MCP server, but the gateway returns HTTP 403 while enumerating tools. The same user's CLI token works against the same endpoint. Root cause appears to be the gateway requiring the legacy user_impersonation scope, which a v2/MSAL client (like Foundry) cannot obtain.

Environment

• Connector gateway: <gateway> (westcentralus)
• MCP server config: <playwright-mcp-config>
• Endpoint: https://app-06.westcentralus.logic.azure.com/api/connectorGateways/<gatewayId>/mcpServerConfigs/<config>/mcp
• Resource (audience): https://apihub.azure.com (Azure API Connections app, fe053c5f-3692-4f14-aef2-ee34fc081cae)

What works

• CLI: az account get-access-token --resource https://apihub.azure.com → MCP Inspector tools/list returns all tools successfully.
• That token's claims: aud=https://apihub.azure.com, oid=<user> (has an access policy on the config), scp=user_impersonation, ver=1.0.

What fails

• Foundry OAuth Identity Passthrough (public client app, redirect https://global.consent.azure-apim.net/redirect/<id>, scope https://apihub.azure.com/Runtime.All) → 403 Forbidden: "Access denied … while enumerating tools."
• Same user oid, same aud, same authorized access policy on the mcpserverconfig. The only differing claim is scp=Runtime.All (v2 flow) vs user_impersonation (v1 flow).
• Also tried scope https://apihub.azure.com/.default → same 403.

Why this can't be fixed client-side

• Azure API Connections (the resource for apihub.azure.com) exposes only Runtime.All as a delegated scope.
• user_impersonation is only produced by the legacy v1 --resource flow. Requesting it explicitly as a v2 scope fails: az account get-access-token --scope https://apihub.azure.com/Runtime.All returns AADSTS65002 (first-party CLI not preauthorized for that scope).
• A v2/MSAL client (Foundry passthrough) can therefore only ever obtain Runtime.All, never user_impersonation.

Ask

1. Does the MCP/gateway token validation require the legacy user_impersonation scope? If so, please also accept Runtime.All — the only delegated scope the apihub.azure.com resource exposes, and all a v2/MSAL client can request.
2. If there is a different supported way for a v2/MSAL client (e.g., Foundry OAuth Identity Passthrough) to obtain a token the gateway accepts, please document it.

Note

I could not decode Foundry's exact outbound token to 100%-confirm scp is the rejected claim — tenant Conditional Access blocks the device-code flow used to reproduce it. However, aud/oid are confirmed valid, and appid is ruled out (the CLI's appid is not in any access policy yet its token works), leaving scp as the only differentiator.