Power Apps

How to ship multi auth'd MCP server connector

(1) Share

Report

Posted on by VK-09041019-0

Hello,

I have an MCP server which supports 3 kinds of authentication mechanism,

1. API key auth

2. Oauth

3. Microsoft's Service Principal auth.

{
"properties": {
"connectionParameterSets": {
"uiDefinition": {
"displayName": "Authentication Type",
"description": "Type of authentication to be used."
},
"values": [
{
"name": "api-key-auth",
"uiDefinition": {
"displayName": "API Key",
"description": "Connect using an API key."
},
"parameters": {
"api_key": {
"type": "securestring",
"uiDefinition": {
"displayName": "API Key",
"description": "The API Key for this api",
"tooltip": "Provide your API Key",
"schema": {
"description": "The API Key for this api",
"type": "securestring"
},
"constraints": {
"tabIndex": 2,
"clearText": false,
"required": "true"
}
}
}
}
},
{
"name": "oauth2-auth",
"uiDefinition": {
"displayName": "OAuth Connection (Enlyft Login)",
"description": "Sign in using your Enlyft login"
},
"parameters": {
"token": {
"type": "oauthSetting",
"oAuthSettings": {
"identityProvider": "oauth2",
"clientId": "m2m_******",
"clientSecret": "6G******",
"scopes": [
"openid email profile offline_access"
],
"redirectMode": "GlobalPerConnector",
"redirectUrl": "https://global.consent.azure-apim.net/redirect/******",
"properties": {
"IsFirstParty": "False"
},
"customParameters": {
"authorizationUrl": {
"value": "https://our.auth.server/oauth/authorize"
},
"tokenUrl": {
"value": "https://our.auth.server/oauth/token"
},
"refreshUrl": {
"value": "https://our.auth.server/oauth/token"
}
}
},
"uiDefinition": {
"displayName": "OAuth Connection",
"description": "Sign in using your Enlyft login",
"constraints": {
"required": "true",
"hidden": "false"
}
}
}
},
"metadata": {
"allowSharing": false
}
},
{
"name": "oAuthClientCredentials",
"uiDefinition": {
"displayName": "Service Principal Connection",
"description": "Service Principal Connection"
},
"parameters": {
"token": {
"type": "oauthSetting",
"oAuthSettings": {
"identityProvider": "aad",
"clientId": "94********",
"scopes": [
"openid email profile"
],
"redirectMode": "GlobalPerConnector",
"redirectUrl": "https://global.consent.azure-apim.net/redirect/cr76b-5fenlyft-20mcp-5fdfe306432e985ff0",
"properties": {
"IsFirstParty": "False",
"AzureActiveDirectoryResourceId": "api://94******",
"IsOnbehalfofLoginSupported": true
},
"customParameters": {
"grantType": {
"value": "client_credentials"
},
"LoginUri": {
"value": "https://login.microsoftonline.com"
},
"TenantId": {
"value": "d4*******"
},
"ResourceUri": {
"value": "api://94*********"
},
"EnableOnbehalfOfLogin": {
"value": "false"
}
}
},
"uiDefinition": {
"displayName": "Service Principal Connection",
"description": "Service Principal Connection",
"constraints": {
"required": "false",
"hidden": "true"
}
}
},
"token:clientId": {
"type": "string",
"uiDefinition": {
"displayName": "Client ID",
"schema": {
"type": "string",
"description": "Client (or Application) ID of your application"
},
"constraints": {
"required": "true",
"hidden": "false"
}
}
},
"token:clientSecret": {
"type": "securestring",
"uiDefinition": {
"displayName": "Client Secret",
"schema": {
"type": "securestring",
"description": "Client secret of your application"
},
"constraints": {
"required": "true",
"hidden": "false"
}
}
},
"token:TenantId": {
"type": "string",
"uiDefinition": {
"displayName": "Tenant",
"schema": {
"type": "string",
"description": "The tenant ID of your application"
},
"constraints": {
"required": "true",
"hidden": "false"
}
}
}
},
"metadata": {
"allowSharing": true
}
}
]
},
"iconBrandColor": "#FCFCFC",
"capabilities": [
"actions"
],
"policyTemplateInstances": [],
"publisher": "Vivek Kothari"
}
}

With this I am able to see a screen like below.

This works in my powerapps environment where I am developing the solution as it has the client secret, but when I export this as a managed solution and import it in different environment, and try the oauth, I get following error,

OAuth2 Authorization Flow failed for service Generic Oauth 2. No key 'clientsecret' for code={Code}&grant_type=authorization_code&redirect_uri={RedirectUrl}&client_id={ClientId}&client_secret={ClientSecret}

I checked the managed solution zip and the client secret is removed (understandable), but my question is then how am I able to distribute my solution while ensuring that the client secret of my Oauth app is securely distributed to all my users?

Screenshot 2026-0...

Your file is currently under scan for potential threats. Please wait while we review it for any viruses or malicious content.

Categories:

AI Builder

Building Power Apps

Connector development

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Haque 3,031 on at

Like (1)

Report
Copy link

Link copied!
Hi @VK-09041019-0,

Let's do error analysis:
The error message “No key 'clientsecret' for code=...&client_secret={ClientSecret}” means the OAuth token request is missing the actual client secret value, likely because it wasn’t set or passed correctly in the target environment.

The error you’re encountering when exporting your PowerApps solution as a managed solution and importing it into another environment typically happens because the client secret value (clientsecret) is not included or configured in the target environment’s OAuth setup.

Here are key points and guidance to resolve this:

Client Secret Storage: In your development environment, the client secret is likely stored in a secure configuration or environment variable accessible to your app. When exporting as a managed solution, this secret is not automatically transferred for security reasons.

Environment-Specific Configuration: Each environment must have its own OAuth client secret configured. You need to set the client secret in the target environment’s connection or custom connector configuration after import.

Power Platform Connection References: Use connection references in your solution to abstract OAuth connection details. After importing the managed solution, update the connection references in the target environment with valid credentials, including client secret.

OAuth Parameters in Custom Connectors: If you use a custom connector with OAuth 2.0, ensure the client secret is configured in the connector’s security settings in each environment. The OAuth flow requires the client secret to be present for the token request.

No Hardcoding Secrets: Never hardcode client secrets in your app or flows. Always use environment variables, Azure Key Vault, or connection references to manage secrets securely.

Your question is: "How am I able to distribute my solution while ensuring that the client secret of my Oauth app is securely distributed to all my users?"

Answer is: When distributing a managed Power Platform solution that uses OAuth with a client secret, the client secret itself is intentionally excluded from the solution package for security reasons. To securely distribute and manage the client secret across environments, the recommended approach is:

1. Do not embed the client secret in the solution package. Instead, treat it as an environment-specific secret that must be configured separately in each target environment.

2. Use Connection References and Environment Variables: Define connection references in your solution to abstract the OAuth connection. After importing the managed solution into a new environment, update the connection references to point to connections configured with the appropriate client secret for that environment. Store the client secret securely in environment variables or Azure Key Vault, and reference these in your connection or custom connector configuration.

3. Manual or Automated Post-Import Configuration: Provide administrators or deployment scripts with instructions or automation to set the client secret securely in each environment after solution import. This can be done via Power Platform admin center, PowerShell scripts, or Azure DevOps pipelines.

4. Use Azure AD App Registration Best Practices: Use certificates instead of client secrets where possible for better security and easier rotation. Manage app registration permissions and secrets centrally in Azure AD.

This approach ensures that your solution package remains secure and portable, while client secrets are managed securely and separately per environment.

Please let me know if this resolves your issue.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No
VK-09041019-0 6 on at

Like (1)

Report
Copy link

Link copied!

Thanks Haque.

"clientId": "@environmentVariables(\"enlyft_OAuthClientId\")",

"clientSecret": "@environmentVariables(\"enlyft_OAuthClientSecret\")",

You mean something like above?

But if I understand what you are saying correctly, when my connector is published, each of my customer would need to get the client secret right? That will not work out for me as we cannot share it.

So what is the recommended way of building Oauth based MCP server's connector for copilot studio?

Could you please share some documentation for this?

Note that we already have a certified connector: https://learn.microsoft.com/en-gb/connectors/enlyftmcp/#enlyft-mcp
We are now adding support for oauth as well, earlier we only had API key support.

Was this reply helpful? Yes No
Suggested answer

Haque 3,031 on at

Like (1)

Report
Copy link

Link copied!
Hi @VK-09041019-0,

Yes, you brought up exactly the right pattern (ClientID and ClientSecret) for managing OAuth client credentials securely in Power Platform solutions.

However, as you correctly understand, the client secret itself is not distributed with the managed solution. Each customer or target environment must configure their own client secret securely after importing the solution. This is by design to prevent sharing sensitive secrets across tenants or environments.

The recommended way to build an OAuth-based MCP server connector for Copilot Studio is to implement the OAuth 2.0 Authorization Code Flow, which is the industry standard for secure delegated access. This approach allows your MCP server to securely authenticate users and authorize access without exposing credentials.

Key points for building this connector include:

Register your MCP server API as an Azure AD application (Microsoft Entra ID app registration).

Configure the app to support OAuth 2.0 Authorization Code Flow with a client ID, client secret (or certificate), and redirect URI.

Implement token validation on your MCP server to verify JWT access tokens issued by Azure AD.

In Copilot Studio, configure the MCP tool to use OAuth 2.0 Authorization Code Flow by specifying the authorization endpoint, token endpoint, client ID, and redirect URI.

Use connection references or environment variables to manage client secrets securely per environment.

Optionally, expose your MCP server behind Azure API Management (APIM) to add security, scalability, and centralized OAuth enforcement.

Follow Microsoft’s labs and deployment guides for detailed step-by-step instructions on configuring OAuth 2.0 with MCP servers and Copilot Studio agents.

References:

Deployment Guide-Copilot Studio agent with MCP Server

Step-by-Step Deployment Guide

Lab MCS3 - Defining Tools

Lab 10: Connect Declarative Agent to OAuth-Protected MCP Server

Consuming an MCP server with OAuth 2.0 in Copilot Studio

Was this reply helpful? Yes No
Suggested answer

11manish 2,286 on at

Like (0)

Report
Copy link

Link copied!

The client secret is intentionally removed from managed solutions for security reasons, as secrets must not be distributed with solution artifacts.

This is why your OAuth flow fails after import. The correct approach is to create the connection in each target environment and provide the client secret there, or

store it securely in Azure Key Vault and retrieve it at runtime.

For scalable and secure implementations, using service principal authentication or environment-specific connections is the recommended pattern.

Was this reply helpful? Yes No