Edit

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

  • Article

Applies to: Azure Logic Apps (Consumption + Standard)

In logic app workflows, some triggers and actions support using a managed identity for authenticating access to resources protected by Azure Active Directory (Azure AD). When you use a managed identity to authenticate your connection, you don't have to provide credentials, secrets, or Azure AD tokens. 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 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 article shows how to enable and set up a managed identity for your logic app and provides an example for how to use the identity for authentication. Unlike the system-assigned identity, which you don't have to manually create, you do have to manually create the user-assigned identity. This article shows how to create a user-assigned identity using the Azure portal and Azure Resource Manager template (ARM template). For Azure PowerShell, Azure CLI, and Azure REST API, review 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

- Integration service environment (ISE)		 - 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)

- Azure Arc enabled Logic Apps		 - 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 more information about managed identity limits in Azure Logic Apps, review Limits on managed identities for logic apps. For more information about the Consumption and Standard logic app resource types and environments, review the following documentation:

Where you can use a managed identity

Only specific built-in and managed connector operations that support Azure AD Open Authentication (Azure AD OAuth) can use a managed identity for authentication. The following table provides only a sample selection. For a more complete list, review Authentication types for triggers and actions that support authentication and Azure services that support Azure AD authentication with managed identities.

The following table lists the connectors that support using a managed identity in a Consumption logic app workflow:

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 Azure AD
- SQL Server

Prerequisites

  • An Azure account and subscription. If you don't have a subscription, sign up for a free 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 Azure AD administrator permissions that can assign roles to identities in the corresponding Azure AD 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 Azure portal

  1. In the Azure portal, go to your logic app resource.

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

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

    Screenshot showing Azure portal with Consumption logic app's "Identity" pane and "System assigned" tab with "On" and "Save" selected.

    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 have to 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 Azure AD and is represented by an object ID.

    Screenshot showing Consumption logic app's "Identity" pane with the 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 an Azure AD tenant.

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

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 Azure AD tenant. This GUID sometimes appears as an "object ID" or objectID.
tenantId <Azure-AD-tenant-ID> The Globally Unique Identifier (GUID) that represents the Azure AD tenant where the logic app is now a member. Inside the Azure AD 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 Logic App (Consumption) or Logic App (Standard) resource, you have to first create that identity as a separate Azure resource.

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

    Screenshot showing Azure portal with "Managed Identities" selected.

  2. On the Managed Identities pane, select Create.

    Screenshot showing "Managed Identities" pane and "Create" selected.

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

    Screenshot showing "Create User Assigned Managed Identity" pane with managed identity details.

    Property Required Value Description
    Subscription Yes <Azure-subscription-name> The name for the Azure subscription to use
    Resource group Yes <Azure-resource-group-name> The name for the Azure resource group to use. 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 West US.
    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 pane, select User assigned > Add.

    Screenshot showing Consumption logic app and "Identity" pane with "Add" selected.

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

    1. From the Subscription list, select your Azure subscription, if not already selected.

    2. From the list with all the managed identities in that 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 showing Consumption logic app and the user-assigned identity selected.

    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 showing Consumption logic app and association between user-assigned identity and logic app resource.

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

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 definition for an HTTP PUT request and includes a non-parameterized identity object. The response to the PUT request and subsequent GET operation also have 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. This 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.

Note

In some cases, you might need the identity to have 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, review 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, review 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's 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, review Azure AD 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, review 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, review the documentation, 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, review 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 showing the Azure portal and key vault example with "Access policies" pane open.

  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 showing "Permissions" tab with "List" permissions selected.

  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, review 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 triggers and actions support letting you add an authentication type. For more information, review Authentication types for triggers and actions that support authentication.

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

    • Built-in 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 showing example built-in action with "Add new parameter" list open and "Authentication" selected in Consumption.

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

        Screenshot showing example built-in action with "Authentication type" list open and "Managed identity" selected in Consumption.

      For more information, review 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 showing Azure Resource Manager action and "Connect with managed identity" selected in Consumption.

      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 showing the connection name page and single managed identity selected in Consumption.

        • 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 showing the connection name page and "Logic Apps Managed Identity" selected in Consumption.

        For more information, review 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, review these topics:

- 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 showing Azure portal with Consumption logic app workflow and HTTP action set up to access resource.

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

    Screenshot showing Consumption workflow with HTTP action and "Add new parameter" list open with "Authentication" property selected.

    Note

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

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

    Screenshot showing Consumption workflow with HTTP action and "Authentication" property with "Managed identity" value selected.

  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 showing Consumption workflow with HTTP action and "Managed identity" property with "System-assigned managed identity" value elected.

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

      Screenshot showing Consumption workflow with HTTP action and "Managed identity" property with user-assigned identity selected.

    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.azure.com/ 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.net. 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 Azure Active Directory (AD) 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 Azure AD.

    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.windows.net, for a specific storage account.

    Screenshot showing Consumption workflow with HTTP action and "Audience" property set to target resource ID.

    For more information about authorizing access with Azure AD for Azure Storage, review 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 Azure AD tenant, select Connect with managed identity.

    Screenshot showing Azure Resource Manager action and "Connect with managed identity" selected.

  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 pane 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 pane 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 showing Azure Resource Manager action with the connection name entered and "System-assigned managed identity" selected.

    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 Azure AD 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 Logic App (Consumption) 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 apps 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 apiVersion property is set to 2016-06-01.
  • The kind property is set to V1 for a Consumption logic app.
  • The parameterValueType property is set to Alternative.
{
    "type": "Microsoft.Web/connections",
    "name": "[variables('connections_azureautomation_name')]",
    "apiVersion": "2016-06-01",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureautomation')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureautomation_name')]",
        "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 apiVersion property is set to 2018-07-01-preview.
  • 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": "2018-07-01-preview",
    "name": "[variables('connections_azureblob_name')]",
    "location": "[parameters('location')]",
    "kind": "V1",
    "properties": {
        "alternativeParameterValues":{},
        "api": {
            "id": "[subscriptionResourceId('Microsoft.Web/locations/managedApis', parameters('location'), 'azureblob')]"
        },
        "customParameterValues": {},
        "displayName": "[variables('connections_azureblob_name')]",
        "parameterValueSet":{
            "name": "managedIdentityAuth",
            "values": {}
        }
    }
}

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.net",
         "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.net",
         "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.net",
         "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 Azure AD.

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, review 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, review Administrator role permissions in Azure Active Directory.

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