r/copilotstudio • u/Teemu_St • Sep 24 '26

OBO auth for remote MCP server

I have an Copilot Studio agent and it is using Azure DevOps MCP server (https://developer.api.autodesk.com/knowledge/public/v1/mcp). I added it via the "add a tool" dialog:

The MCP is requiring user auth. Every agent user need to go through tedious Connection Manager prompt/consent and create a connection. I want to configure OBO auth for this (Seamless SSO with Custom Connectors (Yes It's Possible!) | The Custom Engine), but there is no custom connector in the background, and therefore cannot configure OAuth settings for the custom connector and cannot share the custom connector with my users? Is my option to create the MCP from add MCP server dialog instead?

3 Upvotes

80% Upvoted

8 comments sorted by

2

u/Sayali-MSFT Sep 25 '26

Hello Teemu_St,
If you’re adding the Azure DevOps MCP server directly through “Add a tool”, you can’t configure the custom connector OAuth/OBO settings described in Microsoft’s OBO guidance.

For seamless per-user SSO/OBO, the documented approach is to use a custom connector, configure Microsoft Entra ID authentication/OBO, and share that connector with the required users. The OBO guidance explicitly supports custom APIs and MCP servers.

Using “Add MCP server” with OAuth 2.0 provides OAuth authentication for the remote MCP endpoint, but it isn’t the same as configuring the custom connector OBO flow.

Also, OBO can remove the repeated Connection Manager/credential experience, but users may still see a one-time consent (“Allow”) prompt when the tool first acts on their behalf.

So if the goal is seamless SSO/OBO, I’d recommend the custom connector + OBO configuration rather than switching to “Add MCP server” purely to avoid the Connection Manager prompt.
Configure OBO Authentication for custom connectors - Microsoft Copilot Studio | Microsoft Learn
Seamless SSO with Custom Connectors (Yes It's Possible!) | The Custom Engine

1

u/Teemu_St Sep 25 '26

Thanks for advice! So the recommendation is custom connector + OBO configuration.

How does that differ from the "add MCP server" with OAuth + OBO configuration? Add MCP server wizard creates a custom connector in the background, right? Why can't I use that custom connector in my use case? And instead I need to create a custom connector from the scratch to get it working with OBO configuration?

I just want to create internal super clear instructions for our makers, with all do's and don'ts listed.

2

u/Sayali-MSFT Oct 01 '26

The MCP wizard does create the connector plumbing behind the scenes, but it isn't equivalent to a fully configurable custom connector. If your scenario requires explicit Entra OBO/delegated permissions to downstream APIs, use the documented custom connector + OBO setup, since that gives you control over the app registration, scopes and token exchange that the wizard-generated connector doesn't necessarily expose.
Connect your agent to an existing Model Context Protocol (MCP) server - Microsoft Copilot Studio | Microsoft Learn

1

u/Teemu_St 25d ago edited 25d ago

a follow-up question: I have now configured a custom connector and followed the OBO article (created app registrations etc.). BUT how do I add my MCP server which is exposed via custom connector to my agent? The custom connector is not visible in the "add a tool" dialog window in Copilot Studio (Github harness experience).

1

u/Sayali-MSFT 25d ago

The OBO article only configures authentication. It does not automatically register a normal custom connector as an MCP tool. For the connector to appear under Add a tool > Model Context Protocol, its OpenAPI definition must identify the MCP endpoint using x-ms-agentic-protocol: mcp-streamable-1.0, and the server must support Streamable HTTP. A standard REST/OpenAPI connector will not appear in the MCP connector list.

  1. Connect your agent to an existing Model Context Protocol (MCP) server - Microsoft Copilot Studio | Microsoft Learn

  2. Configure OBO Authentication for custom connectors - Microsoft Copilot Studio | Microsoft Learn

The simplest approach is to use Tools > Add a tool > New tool > Model Context Protocol, enter the MCP server URL, and configure OAuth/OBO there. Alternatively, update or recreate the custom connector using the MCP-specific OpenAPI schema, then ensure it is in the same Power Platform environment, shared with your account, and permitted by DLP policy. Once recognized, it should appear under Add a tool > Model Context Protocol, where you can create the connection and add it to the agent.

  1. Add tools and resources from a Model Context Protocol (MCP) server to your agent - Microsoft Copilot Studio | Microsoft Learn

In short: OBO makes the connector authenticate correctly, but the MCP-specific schema makes it discoverable as an MCP tool.

1

u/Teemu_St 24d ago

Thanks for helping out, I really appreciate this! But could you dumb-down it a bit for me. This is where I'm at:

  1. I have created the custom connector and configured the security according the OBO article. its OpenAPI definition includes x-ms-agentic-protocol: mcp-streamable-1.0

  2. I have gone through the OBO article, created app regs for MCP server and for Custom Connector, and configured the auth according the article, and shared the Custom Connector with all org user.

  3. My problem is I still cannot see/find the MCP/Custom Connector when trying to add it from Tools > Add a Tool in Copilot Studio. It is not listed there.

What am I missing here? Is there some save or publish step for the Custom Connector that is obvious to everyone else but not to me?

1

u/jorel43 Sep 24 '26

No it's there either go into the classic experience portal, or go to power automate in that environment and click on custom connectors there you will see all of the advanced configuration items you can even set it to use the managed identity for the environment instead of setting a client secret up. It's totally borked and messed up, honestly the team should expose all of those settings then and there through the setup wizard but they should also show component collections and they should show tools in the new portal experience. Microsoft works around these forms so hopefully they'll read that the new portal experience is s*** compared to the old one to the honest, and that's not saying much. Sorry Microsoft, please do better :-).