Power Platform Community Forum Thread Details

Hi Copilot Studio team,

We’re testing dynamic discovery for our MCP server in Copilot Studio by providing only the MCP server URL, and we’re seeing an audience mismatch during authentication.

We are not using manually configured OAuth fields. Our MCP server supports dynamic discovery, and the expectation is that Copilot Studio should discover the OAuth configuration automatically from the MCP metadata.

What we entered in Copilot Studio
---------------------------------

Server URL: https://mcpservers.rhythms.ai/rhythms/mcp

Authentication: OAuth 2.0 -> Dynamic discovery

What happens
------------

The connection flow proceeds, but our MCP server rejects the bearer token with this warning:

Bearer token rejected for client user...:
audience mismatch (got 'client01J8PP2MDW8B797TVC7CF5JYH8',
expected 'https://mcpservers.rhythms.ai/rhythms/mcp')

The corresponding client-facing error is:

{
"error": "invalidtoken",
"errordescription": "Authentication failed. The provided bearer token is invalid, expired, or no longer recognized by the server..."
}

What this means on our side
---------------------------

The token appears valid enough to decode and inspect, but its aud claim is for the WorkOS client/application (client...) instead of the MCP protected resource URL.

Our server expects: aud = https://mcpservers.rhythms.ai/rhythms/mcp

But Copilot Studio appears to be sending: aud = client...

What we have verified
---------------------

Our MCP server exposes the expected discovery endpoints:

MCP endpoint:
https://mcpservers.rhythms.ai/rhythms/mcp

Protected resource metadata:
https://mcpservers.rhythms.ai/.well-known/oauth-protected-resource/rhythms/mcp

Authorization server metadata:
https://mcpservers.rhythms.ai/.well-known/oauth-authorization-server

The live protected-resource metadata returns:

resource = https://mcpservers.rhythms.ai/rhythms/mcp
authorizationservers = ["https://accounts.rhythms.ai/"]

The authorization-server metadata also resolves correctly and proxies the WorkOS/AuthKit metadata.

On the WorkOS side, we have verified:

Dynamic Client Registration enabled
Client ID Metadata Document enabled
MCP resource indicator configured for
https://mcpservers.rhythms.ai/rhythms/mcp

We also confirmed that other MCP clients like Claude and ChatGPT work correctly against the same MCP server and WorkOS setup.

Request
-------

Could you help confirm whether Copilot Studio dynamic discovery is expected to request an access token whose audience matches the MCP protected resource URL?

Specifically:

1. Should Copilot Studio, when using dynamic discovery, request a token for the MCP resource value from /.well-known/oauth-protected-resource/...?
2. Is there any known issue where Copilot Studio instead requests or reuses a token scoped to the OAuth client/application id (client...)?
3. Are there any additional requirements for MCP servers using WorkOS/AuthKit-style protected-resource discovery that Copilot Studio expects?

We can share:

HAR capture
exact metadata responses
timestamps
server-side logs

Thanks,
Vansh
Rhythms AI

If you want, I can also tighten this into a shorter, more Microsoft-support-style version.

Categories:

Model context protocol

Hi Vansh,

Thank you for the detailed report.

To answer your questions directly:

1. Should Copilot Studio request a token with aud matching the MCP resource URL?
Yes — when using Dynamic Discovery, Copilot Studio should read the resource value from /.well-known/oauth-protected-resource and include it as the audience in the token request.

2. Is there a known issue where the client ID is used as the audience instead?
This behavior is consistent with the resource parameter (RFC 8707) not being sent in the token request. When resource is omitted, WorkOS defaults the aud to the client_id — which matches what you're seeing.

3. Any additional requirements for WorkOS/AuthKit-style discovery?
No — your server-side setup looks correct. No changes are needed on your end.

Recommended workaround:

Switch from Dynamic Discovery to Manual OAuth 2.0 in Copilot Studio:
Open your MCP server connection in Copilot Studio
Under Authentication → OAuth 2.0, select Manual
Fill in the fields using your WorkOS metadata:

Client ID / Secret
Authorization URL
Token URL
Scopes (if required)

Save and re-test

This bypasses the dynamic discovery flow and gives you direct control over the token parameters, which should resolve the audience mismatch.

Please share your HAR capture if the issue persists after switching to Manual — that will help confirm whether the resource parameter is present in the token request.

Hope this helps!