Authenticate access and connections to Azure resources with managed identities in Azure Logic Apps

  • Article

Applies to: Azure Logic Apps (Consumption + Standard)

When you use a managed identity to authenticate access or connections to Microsoft Entra protected resources from your logic app workflow, you don't have to provide credentials, secrets, or Microsoft Entra tokens. In Azure Logic Apps, some connector operations support using a managed identity when you have to authenticate access to resources protected by Microsoft Entra ID. Azure manages this identity and helps keep authentication information secure because you don't have to manage this sensitive information. For more information, see What are managed identities for Azure resources?.

Azure Logic Apps supports the system-assigned managed identity and the user-assigned managed identity. The following list describes some differences between these managed identity types:

  • A logic app resource can enable and use only one unique system-assigned identity.

  • A logic app resource can share the same user-assigned identity across a group of other logic app resources.

This guide shows how to complete the following tasks:

  • Enable and set up the system-assigned managed identity for your logic app resource. This guide provides an example that shows how to use the identity for authentication.

  • Create and set up a user-assigned identity. This guide shows how to create a user-assigned identity using the Azure portal and Azure Resource Manager template (ARM template) and how to use the identity for authentication. For Azure PowerShell, Azure CLI, and Azure REST API, see the following documentation:

Tool Documentation
Azure PowerShell Create user-assigned identity
Azure CLI Create user-assigned identity
Azure REST API Create user-assigned identity

Consumption versus Standard logic apps

Based on your logic app resource type, you can enable either the system-assigned identity, user-assigned identity, or both at the same time:

Logic app Environment Managed identity support
Consumption - Multi-tenant Azure Logic Apps - Your logic app can enable either the system-assigned identity or the user-assigned identity.

- You can use the managed identity at the logic app resource level and connection level.

- If you enable the user-assigned identity, your logic app can have only one user-assigned identity at a time.
Standard - Single-tenant Azure Logic Apps

- App Service Environment v3 (ASEv3)
- You can enable both the system-assigned identity, which is enabled by default, and the user-assigned identity at the same time.

- You can use the managed identity at the logic app resource level and connection level.

- If you enable the user-assigned identity, your logic app resource can have multiple user-assigned identities at a time.

For information about managed identity limits in Azure Logic Apps, see Limits on managed identities for logic apps. For more information about the Consumption and Standard logic app resource types and environments, see the following documentation:

Where you can use a managed identity

In Azure Logic Apps, only specific built-in and managed connector operations that support OAuth with Microsoft Entra ID can use a managed identity for authentication. The following tables provide only a sample selection. For a more complete list, see Authentication types for triggers and actions that support authentication and Azure services that support Microsoft Entra authentication with managed identities.

For a Consumption logic app workflow, the following table lists the connectors that support managed identity authentication:

Connector type Supported connectors
Built-in - Azure API Management
- Azure App Services
- Azure Functions
- HTTP
- HTTP + Webhook

Note: HTTP operations can authenticate connections to Azure Storage accounts behind Azure firewalls with the system-assigned identity. However, they don't support the user-assigned managed identity for authenticating the same connections.
Managed - Azure App Service
- Azure Automation
- Azure Blob Storage
- Azure Container Instance
- Azure Cosmos DB
- Azure Data Explorer
- Azure Data Factory
- Azure Data Lake
- Azure Event Grid
- Azure Event Hubs
- Azure IoT Central V2
- Azure IoT Central V3
- Azure Key Vault
- Azure Log Analytics
- Azure Queues
- Azure Resource Manager
- Azure Service Bus
- Azure Sentinel
- Azure Table Storage
- Azure VM
- HTTP with Microsoft Entra ID
- SQL Server

Prerequisites

  • An Azure account and subscription. If you don't have a subscription, sign up for a Azure account. Both the managed identity and the target Azure resource where you need access must use the same Azure subscription.

  • The target Azure resource that you want to access. On this resource, you'll add the necessary role for the managed identity to access that resource on your logic app's or connection's behalf. To add a role to a managed identity, you need Microsoft Entra administrator permissions that can assign roles to identities in the corresponding Microsoft Entra tenant.

  • The logic app resource and workflow where you want to use the trigger or actions that support managed identities.

Enable system-assigned identity in the Azure portal

  1. In the Azure portal, open your logic app resource.

  2. On the logic app menu, under Settings, select Identity.

  3. On the Identity page, under System assigned, select On > Save. When Azure prompts you to confirm, select Yes.

    Screenshot shows Azure portal, Consumption logic app, Identity page, and System assigned tab with selected options, On and Save.

    Note

    If you get an error that you can have only a single managed identity, your logic app resource is already associated with the user-assigned identity. Before you can add the system-assigned identity, you must first remove the user-assigned identity from your logic app resource.

    Your logic app resource can now use the system-assigned identity. This identity is registered with Microsoft Entra ID and is represented by an object ID.

    Screenshot shows Consumption logic app, Identity page, and object ID for system-assigned identity.

    Property Value Description
    Object (principal) ID <identity-resource-ID> A Globally Unique Identifier (GUID) that represents the system-assigned identity for your logic app in a Microsoft Entra tenant.

  4. Now follow the steps that give that identity access to the resource later in this guide.

Enable system-assigned identity in an ARM template

To automate creating and deploying logic app resources, you can use an ARM template. To enable the system-assigned identity for your logic app resource in the template, add the identity object and the type child property to the logic app's resource definition in the template, for example:

{
   "apiVersion": "2016-06-01",
   "type": "Microsoft.logic/workflows",
   "name": "[variables('logicappName')]",
   "location": "[resourceGroup().location]",
   "identity": {
      "type": "SystemAssigned"
   },
   "properties": {},
   <...>
}

When Azure creates your logic app resource definition, the identity object gets these other properties:

"identity": {
   "type": "SystemAssigned",
   "principalId": "<principal-ID>",
   "tenantId": "<Azure-AD-tenant-ID>"
}
Property (JSON) Value Description
principalId <principal-ID> The Globally Unique Identifier (GUID) of the service principal object for the managed identity that represents your logic app in the Microsoft Entra tenant. This GUID sometimes appears as an "object ID" or objectID.
tenantId <Azure-AD-tenant-ID> The Globally Unique Identifier (GUID) that represents the Microsoft Entra tenant where the logic app is now a member. Inside the Microsoft Entra tenant, the service principal has the same name as the logic app instance.

Create user-assigned identity in the Azure portal

Before you can enable the user-assigned identity on your Consumption logic app resource or Standard logic app resource, you must create that identity as a separate Azure resource.

  1. In the Azure portal search box, enter managed identities, and select Managed Identities.

    Screenshot shows Azure portal with selected option named Managed Identities.

  2. On the Managed Identities page, select Create.

    Screenshot shows Managed Identities page and selected option for Create.

  3. Provide information about your managed identity, and select Review + Create, for example:

    Screenshot shows page named Create User Assigned Managed Identity, with managed identity details.

    Property Required Value Description
    Subscription Yes <Azure-subscription-name> The Azure subscription name
    Resource group Yes <Azure-resource-group-name> The Azure resource group name. Create a new group, or select an existing group. This example creates a new group named fabrikam-managed-identities-RG.
    Region Yes <Azure-region> The Azure region where to store information about your resource. This example uses China North.
    Name Yes <user-assigned-identity-name> The name to give your user-assigned identity. This example uses Fabrikam-user-assigned-identity.

    After Azure validates the information, Azure creates your managed identity. Now you can add the user-assigned identity to your logic app resource.

Add user-assigned identity to logic app in the Azure portal

  1. In the Azure portal, open your logic app resource.

  2. On the logic app menu, under Settings, select Identity.

  3. On the Identity page, select User assigned > Add.

    Screenshot shows Consumption logic app and Identity page with selected option for Add.

  4. On the Add user assigned managed identity pane, follow these steps:

    1. From the Subscription list, select your Azure subscription.

    2. From the list that has all the managed identities in your subscription, select the user-assigned identity that you want. To filter the list, in the User assigned managed identities search box, enter the name for the identity or resource group.

      Screenshot shows Consumption logic app and selected user-assigned identity.

    3. When you're done, select Add.

      Note

      If you get an error that you can have only a single managed identity, your logic app is already associated with the system-assigned identity. Before you can add the user-assigned identity, you have to first disable the system-assigned identity.

    Your logic app is now associated with the user-assigned managed identity.

    Screenshot shows Consumption logic app with associated user-assigned identity.

  5. Now follow the steps that give that identity access to the resource later in this guide.

Create user-assigned identity in an ARM template

To automate creating and deploying logic app resources, you can use an ARM template. These templates support user-assigned identities for authentication.

In your template's resources section, your logic app's resource definition requires these items:

  • An identity object with the type property set to UserAssigned

  • A child userAssignedIdentities object that specifies the user-assigned resource and name

This example shows a Consumption logic app resource and workflow definition for an HTTP PUT request with a non-parameterized identity object. The response to the PUT request and subsequent GET operation also includes this identity object:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {<template-parameters>},
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicappName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-identity-name>": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": []
      },
   ],
   "outputs": {}
}

If your template also includes the managed identity's resource definition, you can parameterize the identity object. The following example shows how the child userAssignedIdentities object references a userAssignedIdentityName variable that you define in your template's variables section. This variable references the resource ID for your user-assigned identity.

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "Template_LogicAppName": {
         "type": "string"
      },
      "Template_UserAssignedIdentityName": {
         "type": "securestring"
      }
   },
   "variables": {
      "logicAppName": "[parameters(`Template_LogicAppName')]",
      "userAssignedIdentityName": "[parameters('Template_UserAssignedIdentityName')]"
   },
   "resources": [
      {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.logic/workflows",
         "name": "[variables('logicAppName')]",
         "location": "[resourceGroup().location]",
         "identity": {
            "type": "UserAssigned",
            "userAssignedIdentities": {
               "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]": {}
            }
         },
         "properties": {
            "definition": {<logic-app-workflow-definition>}
         },
         "parameters": {},
         "dependsOn": [
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', variables('userAssignedIdentityName'))]"
         ]
      },
      {
         "apiVersion": "2018-11-30",
         "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
         "name": "[parameters('Template_UserAssignedIdentityName')]",
         "location": "[resourceGroup().location]",
         "properties": {}
      }
  ]
}

Give identity access to resources

Before you can use your logic app's managed identity for authentication, you have to set up access for the identity on the Azure resource where you want to use the identity. The way you set up access varies based on the resource that you want the identity to access.

Note

When a managed identity has access to an Azure resource in the same subscription, the identity can access only that resource. However, in some triggers and actions that support managed identities, you have to first select the Azure resource group that contains the target resource. If the identity doesn't have access at the resource group level, no resources in that group are listed, despite having access to the target resource.

To handle this behavior, you must also give the identity access to the resource group, not just the resource. Likewise, if you have to select your subscription before you can select the target resource, you must give the identity access to the subscription.

In some cases, you might need the identity to get access to the associated resource. For example, suppose you have a managed identity for a logic app that needs access to update the application settings for that same logic app from a workflow. You must give that identity access to the associated logic app.

For example, to access an Azure Blob storage account with your managed identity, you have to set up access by using Azure role-based access control (Azure RBAC) and assign the appropriate role for that identity to the storage account. The steps in this section describe how to complete this task by using the Azure portal and Azure Resource Manager template (ARM template). For Azure PowerShell, Azure CLI, and Azure REST API, see the following documentation:

Tool Documentation
Azure PowerShell Add role assignment
Azure CLI Add role assignment
Azure REST API Add role assignment

However, to access an Azure key vault with your managed identity, you have to create an access policy for that identity on your key vault and assign the appropriate permissions for that identity on that key vault. The later steps in this section describe how to complete this task by using the Azure portal. For Resource Manager templates, PowerShell, and Azure CLI, see the following documentation:

Tool Documentation
Azure Resource Manager template (ARM template) Key Vault access policy resource definition
Azure PowerShell Assign a Key Vault access policy
Azure CLI Assign a Key Vault access policy

Assign managed identity role-based access in the Azure portal

To use a managed identity for authentication, some Azure resources, such as Azure storage accounts, require that you assign that identity to a role that has the appropriate permissions on the target resource. Other Azure resources, such as Azure key vaults, require that you create an access policy that has the appropriate permissions on the target resource for that identity.

  1. In the Azure portal, open the resource where you want to use the identity.

  2. On the resource menu, select Access control (IAM) > Add > Add role assignment.

    Note

    If the Add role assignment option is disabled, you don't have permissions to assign roles. For more information, see Microsoft Entra built-in roles.

  3. Now, assign the necessary role to your managed identity. On the Role tab, assign a role that gives your identity the required access to the current resource.

    For this example, assign the role that's named Storage Blob Data Contributor, which includes write access for blobs in an Azure Storage container. For more information about specific storage container roles, see Roles that can access blobs in an Azure Storage container.

  4. Next, choose the managed identity where you want to assign the role. Under Assign access to, select Managed identity > Add members.

  5. Based on your managed identity's type, select or provide the following values:

    Type Azure service instance Subscription Member
    System-assigned Logic App <Azure-subscription-name> <your-logic-app-name>
    User-assigned Not applicable <Azure-subscription-name> <your-user-assigned-identity-name>

    For more information about assigning roles, see Assign roles using the Azure portal.

  6. After you finish, you can use the identity to authenticate access for triggers and actions that support managed identities.

For more general information about this task, see Assign a managed identity access to another resource using Azure RBAC.

Create access policy in the Azure portal

To use a managed identity for authentication, some Azure resources, such as Azure key vaults, require that you create an access policy that has the appropriate permissions on the target resource for that identity. Other Azure resources, such as Azure storage accounts, require that you assign that identity to a role that has the appropriate permissions on the target resource.

  1. In the Azure portal, open the target resource where you want to use the identity. This example uses an Azure key vault as the target resource.

  2. On the resource's menu, select Access policies > Create, which opens the Create an access policy pane.

    Note

    If the resource doesn't have the Access policies option, try assigning a role assignment instead.

    Screenshot shows Azure portal and key vault example with open pane named Access policies.

  3. On the Permissions tab, select the required permissions that the identity needs to access the target resource.

    For example, to use the identity with the managed Azure Key Vault connector's List secrets operation, the identity needs List permissions. So, in the Secret permissions column, select List.

    Screenshot shows Permissions tab with selected List permissions.

  4. When you're ready, select Next. On the Principal tab, find and select the managed identity, which is a user-assigned identity in this example.

  5. Skip the optional Application step, select Next, and finish creating the access policy.

The next section discusses using a managed identity to authenticate access for a trigger or action. The example continues with the steps from an earlier section where you set up access for a managed identity using RBAC and doesn't use Azure Key Vault as the example. However, the general steps to use a managed identity for authentication are the same.

Authenticate access with managed identity

After you enable the managed identity for your logic app resource and give that identity access to the target resource or entity, you can use that identity in triggers and actions that support managed identities.

Important

If you have an Azure function where you want to use the system-assigned identity, first enable authentication for Azure Functions.

These steps show how to use the managed identity with a trigger or action through the Azure portal. To specify the managed identity in a trigger or action's underlying JSON definition, see Managed identity authentication.

  1. In the Azure portal, open your logic app resource.

  2. If you haven't done so yet, add the trigger or action that supports managed identities.

    Note

    Not all connector operations support letting you add an authentication type. For more information, see Authentication types for triggers and actions that support authentication.

  3. On the trigger or action that you added, follow these steps:

    • Built-in connector operations that support managed identity authentication

      1. From the Add new parameter list, add the Authentication property if the property doesn't already appear.

        Screenshot shows Consumption workflow with built-in action and opened list named Add new parameter, with selected option for Authentication.

      2. From the Authentication type list, select Managed identity.

        Screenshot shows Consumption workflow with built-in action and opened list named Authentication type, with selected option for Managed identity.

      For more information, see Example: Authenticate built-in trigger or action with a managed identity.

    • Managed connector operations that support managed identity authentication

      1. On the tenant selection page, select Connect with managed identity, for example:

        Screenshot shows Consumption workflow with Azure Resource Manager action and selected option for Connect with managed identity.

      2. On the next page, for Connection name, provide a name to use for the connection.

      3. For the authentication type, choose one of the following options based on your managed connector:

        • Single-authentication: These connectors support only one authentication type. From the Managed identity list, select the currently enabled managed identity, if not already selected, and then select Create, for example:

          Screenshot shows Consumption workflow, connection name box, and selected option for system-assigned managed identity.

        • Multi-authentication: These connectors show multiple authentication types, but you still can select only one type. From the Authentication type list, select Logic Apps Managed Identity > Create, for example:

          Screenshot shows Consumption workflow, connection name box, and selected option for Logic Apps Managed Identity.

        For more information, see Example: Authenticate managed connector trigger or action with a managed identity.

Example: Authenticate built-in trigger or action with a managed identity

The built-in HTTP trigger or action can use the system-assigned identity that you enable on your logic app resource. In general, the HTTP trigger or action uses the following properties to specify the resource or entity that you want to access:

Property Required Description
Method Yes The HTTP method that's used by the operation that you want to run
URI Yes The endpoint URL for accessing the target Azure resource or entity. The URI syntax usually includes the resource ID for the Azure resource or service.
Headers No Any header values that you need or want to include in the outgoing request, such as the content type
Queries No Any query parameters that you need or want to include in the request. For example, query parameters for a specific operation or for the API version of the operation that you want to run.
Authentication Yes The authentication type to use for authenticating access to the target resource or entity

As a specific example, suppose that you want to run the Snapshot Blob operation on a blob in the Azure Storage account where you previously set up access for your identity. However, the Azure Blob Storage connector doesn't currently offer this operation. Instead, you can run this operation by using the HTTP action or another Blob Service REST API operation.

Important

To access Azure storage accounts behind firewalls by using the Azure Blob connector and managed identities, make sure that you also set up your storage account with the exception that allows access by trusted Microsoft services.

To run the Snapshot Blob operation, the HTTP action specifies these properties:

Property Required Example value Description
Method Yes PUT The HTTP method that the Snapshot Blob operation uses
URI Yes https://<storage-account-name>/<folder-name>/{name} The resource ID for an Azure Blob Storage file in the Azure Global (public) environment, which uses this syntax
Headers For Azure Storage x-ms-blob-type = BlockBlob

x-ms-version = 2019-02-02

x-ms-date = @{formatDateTime(utcNow(),'r')}

 The x-ms-blob-type, x-ms-version, and x-ms-date header values are required for Azure Storage operations.

Important: In outgoing HTTP trigger and action requests for Azure Storage, the header requires the x-ms-version property and the API version for the operation that you want to run. The x-ms-date must be the current date. Otherwise, your workflow fails with a 403 FORBIDDEN error. To get the current date in the required format, you can use the expression in the example value.

For more information, see the following documentation:

- Request headers - Snapshot Blob
- Versioning for Azure Storage services
Queries Only for the Snapshot Blob operation comp = snapshot The query parameter name and value for the operation.

The following example shows a sample HTTP action with all the previously described property values to use for the Snapshot Blob operation:

Screenshot shows Azure portal, Consumption workflow, and HTTP action set up to access resources.

  1. After you add the HTTP action, add the Authentication property to the HTTP action. From the Add new parameter list, select Authentication.

    Screenshot shows Consumption workflow with HTTP action and opened Add new parameter list with selected property named Authentication.

    Note

    Not all triggers and actions support letting you add an authentication type. For more information, see Authentication types for triggers and actions that support authentication.

  2. From the Authentication type list, select Managed identity.

    Screenshot shows Consumption workflow, HTTP action, and Authentication property with selected option for Managed identity.

  3. From the managed identity list, select from the available options based on your scenario.

    • If you set up the system-assigned identity, select System-assigned managed identity if not already selected.

      Screenshot shows Consumption workflow, HTTP action, and Managed identity property with selected option for System-assigned managed identity.

    • If you set up a user-assigned identity, select that identity if not already selected.

      Screenshot shows Consumption workflow, HTTP action, and Managed identity property with selected user-assigned identity.

    This example continues with the System-assigned managed identity.

  4. On some triggers and actions, the Audience property also appears for you to set the target resource ID. Set the Audience property to the resource ID for the target resource or service. Otherwise, by default, the Audience property uses the https://management.chinacloudapi.cn/ resource ID, which is the resource ID for Azure Resource Manager.

    For example, if you want to authenticate access to a Key Vault resource in the global Azure cloud, you must set the Audience property to exactly the following resource ID: https://vault.azure.cn. This specific resource ID doesn't have any trailing slashes. In fact, including a trailing slash might produce either a 400 Bad Request error or a 401 Unauthorized error.

    Important

    Make sure that the target resource ID exactly matches the value that Microsoft Entra ID expects, including any required trailing slashes. For example, the resource ID for all Azure Blob Storage accounts requires a trailing slash. However, the resource ID for a specific storage account doesn't require a trailing slash. Check the resource IDs for the Azure services that support Microsoft Entra ID.

    This example sets the Audience property to https://storage.azure.com/ so that the access tokens used for authentication are valid for all storage accounts. However, you can also specify the root service URL, https://<your-storage-account>.blob.core.chinacloudapi.cn, for a specific storage account.

    Screenshot shows Consumption workflow, HTTP action, and Audience" property set to target resource ID.

    For more information about authorizing access with Microsoft Entra ID for Azure Storage, see the following documentation:

  5. Continue building the workflow the way that you want.

Example: Authenticate managed connector trigger or action with a managed identity

The Azure Resource Manager managed connector has an action named Read a resource, which can use the managed identity that you enable on your logic app resource. This example shows how to use the system-assigned managed identity.

  1. After you add the action to your workflow and select your Microsoft Entra tenant, select Connect with managed identity.

    Screenshot shows Consumption workflow, Azure Resource Manager action, and selected option for Connect with managed identity.

  2. On the connection name page, provide a name for the connection, and select the managed identity that you want to use.

    The Azure Resource Manager action is a single-authentication action, so the connection information box shows a Managed identity list that automatically selects the managed identity that's currently enabled on the logic app resource. If you enabled a system-assigned managed identity, the Managed identity list selects System-assigned managed identity. If you had enabled a user-assigned managed identity instead, the list selects that identity instead.

    If you're using a multi-authentication trigger or action, such as Azure Blob Storage, the connection information box shows an Authentication type list that includes the Logic Apps Managed Identity option among other authentication types.

    In this example, System-assigned managed identity is the only selection available.

    Screenshot shows Consumption workflow and Azure Resource Manager action with connection name entered and selected option for System-assigned managed identity.

    Note

    If the managed identity isn't enabled when you try to create the connection, change the connection, or was removed while a managed identity-enabled connection still exists, you get an error appears that you must enable the identity and grant access to the target resource.

  3. When you're ready, select Create.

  4. After the designer successfully creates the connection, the designer can fetch any dynamic values, content, or schema by using managed identity authentication.

  5. Continue building the workflow the way that you want.

Logic app resource definition and connections that use a managed identity

A connection that enables and uses a managed identity are a special connection type that works only with a managed identity. At runtime, the connection uses the managed identity that's enabled on the logic app resource. At runtime, the Azure Logic Apps service checks whether any managed connector trigger and actions in the logic app workflow are set up to use the managed identity and that all the required permissions are set up to use the managed identity for accessing the target resources that are specified by the trigger and actions. If successful, Azure Logic Apps retrieves the Microsoft Entra token that's associated with the managed identity and uses that identity to authenticate access to the target resource and perform the configured operation in trigger and actions.

In a Consumption logic app resource, the connection configuration is saved in the logic app resource definition's parameters object, which contains the $connections object that includes pointers to the connection's resource ID along with the identity's resource ID, if the user-assigned identity is enabled.

This example shows what the configuration looks like when the logic app enables the system-assigned managed identity:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/{connection-name}",
            "connectionName": "{connection-name}",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity"
               }
            },
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/{managed-connector-type}"
         }
      }
   }
}

This example shows what the configuration looks like when the logic app enables a user-assigned managed identity:

"parameters": {
   "$connections": {
      "value": {
         "<action-name>": {
            "connectionId": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/{connection-name}",
            "connectionName": "{connection-name}",
            "connectionProperties": {
               "authentication": {
                  "type": "ManagedServiceIdentity",
                  "identity": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resourceGroupName}/providers/microsoft.managedidentity/userassignedidentities/{managed-identity-name}"
               }
            },
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/{managed-connector-type}"
         }
      }
   }
}

ARM template for API connections and managed identities

If you use an ARM template to automate deployment, and your workflow includes an API connection, which is created by a managed connector such as Office 365 Outlook, Azure Key Vault, and so on that uses a managed identity, you have an extra step to take.

In an ARM template, the underlying connector resource definition differs based on whether you have a Consumption or Standard logic app and whether the connector shows single-authentication or multi-authentication options.

The following examples apply to Consumption logic app resources and show how the underlying connector resource definition differs between a single-authentication connector, such as Azure Automation, and a multi-authentication connector, such as Azure Blob Storage.

Single-authentication

This example shows the underlying connection resource definition for an Azure Automation action in a Consumption logic app that uses a managed identity where the definition includes the attributes:

  • The kind property is set to V1 for a Consumption logic app.
  • The parameterValueType property is set to Alternative.
{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureautomation_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues": {},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_azureautomation_name')]",
        "parameterValueSet": {},
        "parameterValueType": "Alternative"
    }
},

Multi-authentication

This example shows the underlying connection resource definition for an Azure Blob Storage action in a Consumption logic app that uses a managed identity where the definition includes the following attributes:

  • The kind property is set to V1 for a Consumption logic app.
  • The parameterValueSet object includes a name property that's set to managedIdentityAuth and a values property that's set to an empty object.
{
    "type": "Microsoft.Web/connections",
    "apiVersion": "[providers('Microsoft.Web','connections').apiVersions[0]]",
    "name": "[variables('connections_azureblob_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "authenticatedUser": {},
        "connectionState": "Enabled",
        "customParameterValues": {},
        "displayName": "[variables('connections_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        },
        "parameterValueType": "Alternative"
    }
}

Set up advanced control over API connection authentication

When your workflow uses an API connection, which is created by a managed connector such as Office 365 Outlook, Azure Key Vault, and so on, the Azure Logic Apps service communicates with the target resource, such as your email account, key vault, and so on, using two connections:

Conceptual diagram showing first connection with authentication between logic app and token store plus second connection between token store and target resource.

  • Connection #1 is set up with authentication for the internal token store.

  • Connection #2 is set up with authentication for the target resource.

In a Consumption logic app resource, connection #1 is abstracted from you without any configuration options. In the Standard logic app resource type, you have more control over your logic app. By default, connection #1 is automatically set up to use the system-assigned identity.

However, if your scenario requires finer control over authenticating API connections, you can optionally change the authentication for connection #1 from the default system-assigned identity to any user-assigned identity that you've added to your logic app. This authentication applies to each API connection, so you can mix system-assigned and user-assigned identities across different connections to the same target resource.

In your Standard logic app connections.json file, which stores information about each API connection, each connection definition has two authentication sections, for example:

"keyvault": {
   "api": {
      "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
   },
   "connection": {
      "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.cn",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  • The first authentication section maps to connection #1. This section describes the authentication used for communicating with the internal token store. In the past, this section was always set to ManagedServiceIdentity for an app that deploys to Azure and had no configurable options.

  • The second authentication section maps to connection #2. This section describes the authentication used for communicating with the target resource can vary, based on the authentication type that you select for that connection.

Why change the authentication for the token store?

In some scenarios, you might want to share and use the same API connection across multiple logic apps, but not add the system-assigned identity for each logic app to the target resource's access policy.

In other scenarios, you might not want to have the system-assigned identity set up on your logic app entirely, so you can change the authentication to a user-assigned identity and disable the system-assigned identity completely.

Change the authentication for the token store

  1. In the Azure portal, open your Standard logic app resource.

  2. On the resource menu, under Workflows, select Connections.

  3. On the Connections pane, select JSON View.

    Screenshot showing the Azure portal, Standard logic app resource, "Connections" pane with "JSON View" selected.

  4. In the JSON editor, find the managedApiConnections section, which contains the API connections across all workflows in your logic app resource.

  5. Find the connection where you want to add a user-assigned managed identity. For example, suppose your workflow has an Azure Key Vault connection:

    "keyvault": {
   "api": {
      "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity"
   },
   "connection": {
      "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.cn",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  6. In the connection definition, complete the following steps:

    1. Find the first authentication section. If no identity property already exists in this authentication section, the logic app implicitly uses the system-assigned identity.

    2. Add an identity property by using the example in this step.

    3. Set the property value to the resource ID for the user-assigned identity.

    "keyvault": {
   "api": {
      "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/keyvault"
   },
   "authentication": {
      "type": "ManagedServiceIdentity",
      // Add "identity" property here
      "identity": "/subscriptions/{Azure-subscription-ID}/resourcegroups/{resource-group-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{identity-resource-ID}" 
   },
   "connection": {
      "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/<connection-name>"
   },
   "connectionProperties": {
      "authentication": {
         "audience": "https://vault.azure.cn",
         "type": "ManagedServiceIdentity"
      }
   },
   "connectionRuntimeUrl": "<connection-runtime-URL>"
}

  7. In the Azure portal, go to the target resource, and give access to the user-assigned managed identity, based on the target resource's needs.

    For example, for Azure Key Vault, add the identity to the key vault's access policies. For Azure Blob Storage, assign the necessary role for the identity to the storage account.

Disable managed identity

To stop using the managed identity for authentication, first remove the identity's access to the target resource. Next, on your logic app resource, turn off the system-assigned identity or remove the user-assigned identity.

When you disable the managed identity on your logic app resource, you remove the capability for that identity to request access for Azure resources where the identity had access.

Note

If you disable the system-assigned identity, any and all connections used by workflows in that logic app's workflow won't work at runtime, even if you immediately enable the identity again. This behavior happens because disabling the identity deletes the object ID. Each time that you enable the identity, Azure generates the identity with a different and unique object ID. To resolve this problem, you need to recreate the connections so that they use the current object ID for the current system-assigned identity.

Try to avoid disabling the system-assigned identity as much as possible. If you want to remove the identity's access to Azure resources, remove the identity's role assignment from the target resource. If you delete your logic app resource, Azure automatically removes the managed identity from Microsoft Entra ID.

The steps in this section cover using the Azure portal and Azure Resource Manager template (ARM template). For Azure PowerShell, Azure CLI, and Azure REST API, see the following documentation:

Tool Documentation
Azure PowerShell 1. Remove role assignment.
2. Delete user-assigned identity.
Azure CLI 1. Remove role assignment.
2. Delete user-assigned identity.
Azure REST API 1. Remove role assignment.
2. Delete user-assigned identity.

Disable managed identity in the Azure portal

To remove access for the managed identity, remove the identity's role assignment from the target resource, and then disable the managed identity.

Remove role assignment

The following steps remove access to the target resource from the managed identity:

  1. In the Azure portal, go to the target Azure resource where you want to remove access for the managed identity.

  2. From the target resource's menu, select Access control (IAM). Under the toolbar, select Role assignments.

  3. In the roles list, select the managed identities that you want to remove. On the toolbar, select Remove.

    Tip

    If the Remove option is disabled, you most likely don't have permissions. For more information about the permissions that let you manage roles for resources, see Administrator role permissions in Microsoft Entra ID.

Disable managed identity on logic app resource

  1. In the Azure portal, open your logic app resource.

  2. On the logic app navigation menu, under Settings, select Identity, and then follow the steps for your identity:

    • Select System assigned > On > Save. When Azure prompts you to confirm, select Yes.

    • Select User assigned and the managed identity, and then select Remove. When Azure prompts you to confirm, select Yes.

Disable managed identity in an ARM template

If you created the logic app's managed identity by using an ARM template, set the identity object's type child property to None.

"identity": {
   "type": "None"
}

Next steps