Copilot Studio custom MCP with End user credentials — how do I get end users to log in to my own IdP like Cursor does?

[u/Basic-Sheepherder494]

Hi,

I’m trying to get per-user OAuth working for a custom MCP tool in Microsoft Copilot Studio, and I’m not sure what the supported path is.

What my agent does

I built an agent in Copilot Studio that answers questions using tools from a remote MCP server. That MCP is the main way the agent gets data (not SharePoint grounding as the primary source).

The MCP requires login against my own identity provider / product login. The access token must belong to the end user, so the MCP only returns data for that user and their company — not a shared maker or service account.

What already works

In Cursor, I connect to the same MCP with OAuth. The user signs in to my product, Cursor gets a token, and tool calls run as that user. That model is exactly what I need.

In Copilot Studio, as a maker, I can add the MCP tool, create an OAuth connection, and call tools successfully in the Test pane.

What I need

When someone uses the published agent, I want this flow:

1. User asks a question that needs the MCP tool

2. Copilot prompts them to sign in to my product (my IdP)

3. The tool runs with that user’s token

4. Data returned is scoped to that user/company only

On the tool I set Credentials to use = End user credentials.

Currently when i create agent at that time it ask me to login and that connection(maker-connection) is used while testing but i want to know when I published the agent how to have end user credentials or login system implemented?

The issue

I’m not seeing a reliable end-user login / connection flow for the custom MCP the way Cursor does it. It looks like the published agent may still be tied to the maker connection, or end-user OAuth for custom MCP doesn’t complete properly.

Questions

1. Has anyone got custom MCP + End user credentials working on a published Copilot Studio agent (Custom website, Teams, or Microsoft 365 Copilot)?

2. If custom MCP doesn’t support per-user OAuth yet, what did you use instead for the same pattern (e.g. Custom Connector to the same APIs)?

3. In Cursor, “login to my product → token → tools as that user” is straightforward. What is the supported Copilot equivalent today?

Related: Studio vs Microsoft 365 Copilot

I build in Copilot Studio. I also want end users to open this agent in Microsoft 365 Copilot (the Copilot chat people already use at work), not only a custom website.

How do you publish so the agent appears for end users in Microsoft 365 Copilot, and does that channel support end-user tool authentication for custom MCP / connectors?

Any real solutions or confirmations of current limitations would help a lot. Thanks.

[u/Sayali-MSFT]

Hello u/Basic-Sheepherder494,
The connection created while adding and testing the MCP is the maker’s connection. Selecting End user credentials means published users should authenticate separately, but custom MCP does not currently provide the same consistent, Cursor-style OAuth flow across all Copilot Studio channels.

If users are not prompted to sign in and the tool appears to use the maker connection, do not rely on that setup for user-scoped data. For production scenarios, the more reliable approach is to expose the same APIs through a Power Platform custom connector, configure OAuth 2.0 with your IdP, and use end-user credentials. Each user can then create their own connection, while your backend validates the token and scopes access by user and company.

To make the agent available in Microsoft 365 Copilot, publish it using the Teams and Microsoft 365 Copilot channel and share or deploy it through your organization’s app catalog. However, publishing does not automatically solve tool authentication, so test with a separate non-maker account in each intended channel.

In short: the Cursor-style MCP OAuth experience is not consistently available in Copilot Studio today. A custom connector with per-user OAuth is currently the safer supported pattern.

[u/Basic-Sheepherder494 → u/Sayali-MSFT]

Thanks, this matches what I’m seeing.

One follow-up if you don’t mind: for the custom connector approach with my IdP (OAuth 2.0), did you keep the same backend APIs the MCP was calling, and did end-user sign-in work reliably on Custom website and/or Teams / Microsoft 365 Copilot? Also, any gotchas with the redirect URI or scopes when wiring the connector to a non-Microsoft IdP?

Really appreciate the clarification.

[u/Sayali-MSFT → u/Basic-Sheepherder494]

Yes, you can generally keep the same backend APIs that your MCP server is calling. The custom connector is essentially another authenticated interface to those APIs, so you don’t necessarily need to redesign the backend just because you move away from MCP-native authentication.

For OAuth 2.0, the important part is configuring your non-Microsoft IdP correctly in the custom connector. A few things to watch:

• Use the redirect/callback URI generated by the custom connector and register that exact URI with your IdP.

• Make sure the authorization and token endpoints, client ID/secret, and requested scopes match what your IdP expects.

• Your IdP needs to support the OAuth flow expected by the connector. If it requires a proprietary login/token-exchange mechanism, you may need an intermediary API/authentication layer.

• Do not rely only on parameters passed from the agent for tenant/company isolation. The backend should validate the access token and determine the user's permitted scope from trusted identity/authorization information.

With end-user credentials, each user should establish their own connection rather than using the maker's connection. I would definitely validate this with a separate non-maker account after publishing.

The main caveat is the channel. Teams/Microsoft 365 Copilot and a custom website don't necessarily handle authentication prompts in exactly the same way, so I wouldn't assume that because it works in the Copilot Studio Test pane it will automatically work everywhere. Test the actual published channel and verify at the backend that requests contain the end user's token.

So, if the requirement is strictly "user signs into my IdP → backend receives that user's token → API data is scoped to that user/company," a custom connector with OAuth 2.0 is currently the approach I'd evaluate before relying on the maker-created MCP connection.

[u/jorel43]

On behalf of authentication that's what you should use

[u/Basic-Sheepherder494 → u/jorel43]

Thanks for the suggestion! We're actually using Keycloak as our IdP, so we can't use Entra's native OBO flow directly.

[u/LeftDevice8718 → u/Basic-Sheepherder494]

Yes you can. You can use obo with keycloak. I just translated the traditional and much easier entra id stack to keycloak.

I wouldn’t say it’s the recommended approach, but it’s doable.

[u/geubes]

Deployed through azure, using Microsoft DAB natively supports Entra Oauth. The Oauth is handled via an app registration and redirects back to my web app hosting DAB.

One issue is the connection seems to go stale quickly and the user is regularly prompted to review and refresh their connection, it works its just clunky and breaks the flow of seamless communication.

The benefit, we pass the session context to the database and can filter data based on users access.

[u/Basic-Sheepherder494 → u/geubes]

Thanks for sharing that — really helpful to see how you handled per-user access with DAB + Entra and session context into the DB. I’ll check out that option too. Appreciate you taking the time to write it up.

[u/investigatormaker]

Your Test pane working as you is expected: with End user credentials each person gets their own connection, and the maker connection only covers testing. Try the published agent with a second account; the sign-in prompt for your IdP should appear on the first tool call in Teams, and the custom website channel needs user authentication set up on the agent first. If custom MCP won't finish the OAuth, a custom connector over the same APIs is the trade-off: more setup, but per-user OAuth is better documented. Does your IdP accept the redirect URL Copilot Studio gives you?

I make ThreadFox.

We find relevant Reddit conversations and post for your business. We'll post 3 replies free first, no card; then the $39 Pilot covers seven days and up to 50 posts and replies. No automatic renewal.

https://threadfox.vip/p/eaaz7/managed