Azure Logic Apps rely on API connections (Microsoft.Web/connections) to authenticate against external services such as SQL Server, SharePoint, Service Bus, and others. When these connections are created using a personal or corporate user account, the connection is tied to that individual rather than the application.

Why is this an issue?

Using personal or corporate user accounts for API connections introduces several risks:

• Access loss: when the user leaves the organization or their account is disabled, all Logic Apps depending on that connection break silently.
• Credential sharing: the user’s credentials are embedded in a shared resource, violating the principle of least privilege.
• Audit and compliance gaps: actions performed through the connection are attributed to an individual rather than to a service identity, making audits unreliable.
• Privilege abuse: the connection inherits all permissions of the user account, which typically exceed what the workflow needs.

API connections should instead use service principals or managed identities, which provide scoped, rotatable, centrally managed credentials tied to the application rather than a person.

What is the potential impact?

If the user account is disabled or deleted, all dependent Logic Apps will fail. Additionally, the embedded credentials may be over-privileged and difficult to rotate, increasing the blast radius of a compromise.

How to fix it in JSON templates

Use managed identity authentication by setting parameterValueType to "Alternative" instead of embedding user credentials in parameterValues.

Code examples

Noncompliant code example

{
  "type": "Microsoft.Web/connections",
  "apiVersion": "2016-06-01",
  "name": "sql-connection",
  "location": "[resourceGroup().location]",
  "properties": {
    "api": {
      "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', resourceGroup().location, 'sql')]"
    },
    "parameterValues": {
      "server": "myserver.database.windows.net",
      "database": "mydb",
      "username": "john.doe@company.com",
      "password": "[parameters('sqlPassword')]"
    }
  }
}

Compliant solution

{
  "type": "Microsoft.Web/connections",
  "apiVersion": "2016-06-01",
  "name": "sql-connection-mi",
  "location": "[resourceGroup().location]",
  "properties": {
    "api": {
      "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', resourceGroup().location, 'sql')]"
    },
    "parameterValueType": "Alternative",
    "alternativeParameterValues": {
      "server": "myserver.database.windows.net",
      "database": "mydb"
    }
  }
}

How to fix it in Bicep

Use managed identity authentication by setting parameterValueType to 'Alternative' instead of embedding user credentials in parameterValues.

Code examples

Noncompliant code example

resource sqlConnection 'Microsoft.Web/connections@2016-06-01' = {
  name: 'sql-connection'
  location: resourceGroup().location
  properties: {
    api: {
      id: subscriptionResourceId('Microsoft.Web/locations/managedApis', resourceGroup().location, 'sql')
    }
    parameterValues: {
      server: 'myserver.database.windows.net'
      database: 'mydb'
      username: 'john.doe@company.com' // Noncompliant
      password: sqlPassword
    }
  }
}

Compliant solution

resource sqlConnectionMi 'Microsoft.Web/connections@2016-06-01' = {
  name: 'sql-connection-mi'
  location: resourceGroup().location
  properties: {
    api: {
      id: subscriptionResourceId('Microsoft.Web/locations/managedApis', resourceGroup().location, 'sql')
    }
    parameterValueType: 'Alternative'
    alternativeParameterValues: {
      server: 'myserver.database.windows.net'
      database: 'mydb'
    }
  }
}

Resources

Documentation

• Azure - Managed connectors in Azure Logic Apps
• Azure - Authenticate API connection with managed identity
• Azure - Microsoft.Web/connections ARM template reference
• Azure - Secure access and data in Azure Logic Apps