The entry doesn't say which screens changed, which steps were removed, or how the process compares with the old one. So this article doesn't attempt a before-and-after comparison. Instead it covers what Microsoft's current documentation says an admin must do today to connect Copilot to an outside system through OAuth, and where that process tends to break.
What the roadmap entry actually says
- ID: 502530
- Product: Microsoft Copilot (Microsoft 365)
- Status: Launched, General Availability
- Platform: Web
- Cloud: Worldwide (Standard Multi-Tenant)
- GA date (per metadata): December 2025
- Audience: Connector administrators
A few things the entry doesn't support: a specific number of clicks saved, any change to OAuth's security properties, or a new sign-in experience for users. If a vendor deck claims any of those, ask for documentation.
Section summary: This is a modest admin usability update. It matters mostly to teams connecting Copilot to non-Microsoft systems.
Where OAuth fits: custom federated connectors
The OAuth workflow is documented under custom federated connectors. These connect Microsoft 365 Copilot to a Model Context Protocol (MCP) server in real time, and an admin configures them in the Microsoft 365 admin center. Microsoft 365 Copilot supports custom federated connectors — real-time connections to an MCP server, configured by an admin in the Microsoft 365 admin center.
Microsoft offers three authentication methods for these connectors:
| Method | Use case | Setup needed |
|---|---|---|
| Microsoft Entra SSO | Users sign in with Microsoft 365 credentials | Entra app registration plus Teams Developer Portal registration |
| OAuth 2.0 | Users authenticate with a third-party identity provider. | OAuth app in the source system and Teams Developer Portal registration. |
| No Auth | Users don't need to authenticate | None |
Don't confuse this with the other OAuth setup in the Copilot ecosystem: OAuth for declarative-agent plugins. For plugins, Microsoft's extensibility documentation says registering in the Teams developer portal is optional if you use Agents Toolkit or the declarative agent developer skill. The names are similar, but they are separate workflows for different people. Admins use a form in the admin center. Developers ship app packages.
Section summary: OAuth is the method to pick when your data source uses a non-Entra identity provider, such as a SaaS CRM.
Prerequisites checklist
Microsoft's setup guide lists these requirements before you start:
- An MCP server URL that exposes the tools you want Copilot to use, such as search, fetch, query, or create/update/delete tools.
- Network access. If the MCP server filters traffic by source IP, allow Microsoft 365 Copilot's static egress IP addresses. Static egress is on by default and needs no manifest flag.
- Admin role: Global Administrator or AI Administrator in the Microsoft 365 admin center. Entra SSO also needs an appropriate Entra admin role.
- Access to the Teams Developer Portal.
- Developer and legal details: developer name, website URL, privacy policy URL, and terms of use URL.
Step-by-step: OAuth 2.0 for a custom federated connector
The order matters. Set up authentication first, then create the connector.
Step 1: Register the app with your OAuth provider
Before you begin, register your app with your OAuth 2.0 provider to get a client ID and secret. If your provider requires allowed redirect URIs, add this one:
[url]https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect[/url]
Copy the client ID and client secret.
Step 2: Register the OAuth connection in the Teams Developer Portal
- Sign in to the Teams Developer Portal.
- Select Tools > OAuth Client Registration.
- Select + New OAuth connection.
- Fill in the name, client ID, client secret, authorization endpoint, token endpoint, refresh endpoint, and scopes.
- Optionally, turn on Proof Key for Code Exchange (PKCE) if your provider supports it.
- Select Save.
After the registration is saved, the Teams Developer Portal displays the OAuth client registration ID. Copy it. You'll need it in the next step.
Step 3: Create the connector in the admin center
- Sign in to the Microsoft 365 admin center.
- Go to Copilot > Connectors and open the Gallery tab.
- Under Created by your org, find Create a new connector and select Add.
- On the Custom connector page, under Connect to MCP server, select Add.
- Enter a display name, a description, and the base URL of your MCP server.
- For OAuth 2.0, enter the OAuth registration ID from the Teams Developer Portal.
- Select Save.
How you know it worked: the connector shows up in Your Connections. Each user then signs in from Copilot. A third-party implementation guide from Extole describes the result for users: once deployed, each user connects Extole as a source in Copilot Chat and signs in with their Extole account.
Section summary: There are three stops: your identity provider, the Teams Developer Portal, and the admin center. The registration ID is what ties them together.
Rolling it out without surprises
A saved connector isn't automatically available to everyone. Microsoft's documentation describes several controls stacked on top of each other, and a user only gets access if every one of them allows it:
- Agent and plugin access (Agents > Settings). The Allow agents and plugins built by your organization setting governs custom connectors.
- User access (Agents > Settings). This sets the largest group that can ever get the connector.
- Staged rollout. Pilot the connector with selected users or groups, then select Deploy to all users. Even then, it only reaches people already included in User access.
- Enable / Disable / Block. Disabling pauses the connector and keeps its configuration. Blocking in Agents > Tools does the same thing. Delete removes the connector permanently and can't be undone.
Changes can take up to 10 minutes to reach all Microsoft 365 experiences. Users don't need to sign out, but they may need to refresh Copilot or start a new conversation.
Troubleshooting the usual suspects
"It works for me but nobody else." Microsoft's documentation gives three usual causes. The connector may be staged only to the admin. User access may target a group the admin happens to be in. Or other users haven't connected to the service in Settings > Sources.
An entitled user can't find the connector. Microsoft suggests checking these in order:
- The publisher type is allowed, or the connector has been turned on individually.
- The connector is enabled and not blocked.
- The user is included in User access.
- The user is included in the staged rollout.
- The user has a Microsoft 365 Copilot license.
- The 10-minute propagation window has passed and the user has refreshed Copilot.
- The user has signed in to the connector under Settings > Sources.
Your MCP server only supports Dynamic Client Registration (DCR). This catches people out. In a Microsoft Q&A thread, an answer states that DCR is supported for MCP plugins, but it is not currently supported through the Teams Developer Portal or the Microsoft 365 admin-center connector form. The same answer suggests getting the vendor to issue a static client ID and secret for the regular OAuth 2.0 option. The other route is the developer path: Microsoft 365 Agents Toolkit 6.12.0 or later.
The connector works in Chat but not in an Office app. In another Q&A thread, an org-created OAuth connector worked in Copilot Chat but didn't appear in PowerPoint. The responder put this down to app rollout timing, saying PowerPoint support was planned to begin GA starting October 30, and noted that the connector's OAuth configuration wasn't the problem. Before you rebuild a working OAuth registration, check whether the app itself supports these connectors yet.
Copy-paste problems. In a Q&A thread about a Cowork MCP plugin, which is a different scenario but uses the same Teams Developer Portal registration, a user reported that Microsoft Support traced their failure to a trailing space at the end of clientid in OAuthClient registration. Check for stray whitespace in the client ID before assuming something bigger is wrong.
The bigger picture
The real story isn't the "few clicks." It's that Microsoft now expects connecting Copilot to a third-party identity provider to be an admin task done through forms, not a developer task done through app packages. Earlier this year Microsoft featured federated Copilot connectors on its AI at Work roadmap as a way to bring real-time enterprise data into Copilot. Making OAuth easier for connector admins follows directly from that.
A word of caution: easier setup doesn't make OAuth any safer. Fewer clicks can also mean less time spent thinking about which scopes you're granting. Keep scopes minimal and pilot with a staged rollout before you select Deploy to all users. And remember that the admin center only shows what you've allowed, not what users actually see. Microsoft recommends confirming from a non-admin test account under Copilot Chat > Settings > Sources.
Bottom line: Roadmap item 502530 is generally available for worldwide multi-tenant customers. Microsoft hasn't published exactly what changed, but the documented OAuth process is three steps, and most problems come from rollout settings rather than OAuth itself.