Copilot Studio MCP connector omits the RFC 8707 resource parameter, so the token audience is wrong and every MCP call returns 401

Hi @Sebastian Alpers

Thanks for sharing the detailed investigation and network traces. To help us validate this further, could you please check and share the following:

• Confirm whether the same behavior occurs when creating a new** MCP connection in Copilot Studio using OAuth 2.0 → Dynamic (with ****discovery)**.
• Please share the protected-resource metadata returned by your MCP server and the authorization-server metadata, with any sensitive values redacted.
• From the browser network trace, please confirm whether the resource parameter is missing from both** the authorization request and token **request, or only from the authorization request.
• If possible, test with a minimal MCP server/tool and confirm whether tools/list still returns 401 with the same audience mismatch.
• Please also confirm whether authentication itself completes successfully and the failure occurs only when Copilot Studio subsequently invokes the MCP endpoint.
• If available, share the Copilot Studio environment/region and a sanitized HAR/network trace covering discovery, authorization, token exchange, and the failing MCP request.

Once we have these details, we can better isolate whether the behavior is occurring in the Copilot Studio OAuth/DCR flow and consult the engineering team regarding the expected handling of the resource parameter.

Hi @Ashlesha Pawar (Tata Consultancy Services Limited) , thanks for picking this up. Answers in order:

1. New connection with Dynamic (with discovery) Yes. I reproduced it several times on 2026-09-21 and 2026-09-22, each time with a freshly created MCP tool (new connector, new DCR client, new connection). The result was the same with both Dynamic and Dynamic (with discovery). It also happens in a second, unrelated customer tenant and environment.

2. Metadata (hosts redacted)

Unauthenticated POST https://<mcp-host>/mcp returns:

HTTP/2 401
www-authenticate: Bearer resource_metadata="https://<mcp-host>/.well-known/oauth-protected-resource/mcp"

Protected-resource metadata (RFC 9728), GET https://<mcp-host>/.well-known/oauth-protected-resource/mcp:

{"resource":"https://<mcp-host>/mcp","authorization_servers":["https://<auth-host>"],"bearer_methods_supported":["header"]}

Authorization-server metadata (RFC 8414), GET https://<auth-host>/.well-known/oauth-authorization-server:

{
  "issuer": "https://<auth-host>",
  "authorization_endpoint": "https://<auth-host>/oauth2/authorize",
  "token_endpoint": "https://<auth-host>/oauth2/token",
  "registration_endpoint": "https://<auth-host>/oauth2/register",
  "jwks_uri": "https://<auth-host>/oauth2/jwks",
  "introspection_endpoint": "https://<auth-host>/oauth2/introspection",
  "device_authorization_endpoint": "https://<auth-host>/oauth2/device_authorization",
  "scopes_supported": ["email", "offline_access", "openid", "profile"],
  "response_types_supported": ["code"],
  "response_modes_supported": ["query"],
  "grant_types_supported": ["authorization_code", "refresh_token", "urn:ietf:params:oauth:grant-type:device_code"],
  "code_challenge_methods_supported": ["S256"],
  "token_endpoint_auth_methods_supported": ["none", "client_secret_post", "client_secret_basic"],
  "client_id_metadata_document_supported": true
}

3. Authorization request vs. token request The authorization request (the browser redirect) definitely has no resource; it is quoted in the question. The token request isn't in the browser trace, because the Power Platform connector backend (*.azure-apihub.net) exchanges the code server to server. So I can't observe that request directly. The issued token shows the outcome, though: its aud is the authorization server's default client id and not https://<mcp-host>/mcp. So no resource took effect anywhere in the flow. Please check the connector backend's token request on your side.

4. Minimal test tools/list is already the minimal case: it's the first MCP call after initialize, and it doesn't depend on any particular tool. To isolate resource as the only variable, we deployed a small authorize endpoint that forwards the request unchanged except for adding resource=https://<mcp-host>/mcp. We then configured the same Copilot Studio tool in Manual mode with that endpoint as the Authorization URL. Same user, same authorization server, same client:

resource in authorization requestaud``tools/listno (Copilot Studio, Dynamic / Dynamic with discovery)the AS's default client id401 invalid_tokenyes (Manual mode + forwarding endpoint)https://<mcp-host>/mcp200, tools load in Copilot StudioWe use this as a workaround in production now. It only works in Manual mode, with a manually registered client per connector redirect URL, and the credentials have to be edited in the Power Apps custom-connector editor because Copilot Studio locks them after Create. So the dynamic modes still can't be used against an audience-restricted authorization server.

5. Does authentication complete? Yes. The sign-in and consent screens complete, the code is exchanged, and Copilot Studio shows the connection as connected. The failure only happens afterwards, when Copilot Studio calls the MCP endpoint with that token. Our server rejects the token on the aud check (log: unexpected "aud" claim value) and returns 401. Copilot Studio shows this as "Invalid access token".

6. Environment / region and HAR The state value the connector sends ends in _germany-001_azure-apihub.net, so the environment is in the Germany geo. I can share environment IDs, connector names, UTC timestamps and a sanitized HAR covering discovery, authorization and the failing call. They contain tenant identifiers and auth codes, though, so I'd rather not post them in a public thread. Please tell me a private channel (for example a support case number or a private message) and I'll send them there.

Related, possibly the same root cause: issue 1462 in the microsoft/mcp GitHub repository (Copilot Studio → remote MCP, 401 The audience '(null)' is invalid), closed without a public resolution.

Could you also confirm whether this is being tracked as a defect, and share a tracking ID?