Secure access and data in Azure Logic Apps

To control access and protect data in Azure Logic Apps, you can set up security in these areas:

Access to request-based triggers

If your logic app uses a request-based trigger, which receives incoming calls or requests, such as the Request or Webhook trigger, you can limit access so that only authorized clients can call your logic app. All requests received by a logic app are encrypted and secured with Secure Sockets Layer (SSL) protocol.

Here are the ways that you can secure access to this trigger type:

Generate shared access signatures (SAS)

Every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL, which follows this format:

https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

Each URL contains the sp, sv, and sig query parameter as described in this table:

Query parameter Description
sp Specifies permissions for the permitted HTTP methods to use.
sv Specifies the SAS version to use for generating the signature.
sig Specifies the signature to use for authenticating access to the trigger. This signature is generated by using the SHA256 algorithm with a secret access key on all the URL paths and properties. Never exposed or published, this key is kept encrypted and stored with the logic app. Your logic app authorizes only those triggers that contain a valid signature created with the secret key.

For more information about securing access with SAS, see these sections in this topic:

Regenerate access keys

To generate a new secure access key at any time, use the Azure REST API or Azure portal. All previously generated URLs that use the old key are invalidated and no longer have authorization to trigger the logic app. The URLs that you retrieve after regeneration are signed with the new access key.

  1. In the Azure portal, open the logic app that has the key you want to regenerate.

  2. On the logic app's menu, under Settings, select Access Keys.

  3. Select the key that you want to regenerate and finish the process.

Create expiring callback URLs

If you share the endpoint URL for a request-based trigger with other parties, you can generate callback URLs that use specific keys and have expiration dates. That way, you can seamlessly roll keys or restrict access to triggering your logic app based on a specific timespan. To specify an expiration date for a URL, use the Logic Apps REST API, for example:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01

In the body, include the NotAfterproperty by using a JSON date string. This property returns a callback URL that's valid only until the NotAfter date and time.

Create URLs with primary or secondary secret key

When you generate or list callback URLs for a request-based trigger, you can specify the key to use for signing the URL. To generate a URL that's signed by a specific key, use the Logic Apps REST API, for example:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01

In the body, include the KeyType property as either Primary or Secondary. This property returns a URL that's signed by the specified secure key.

Restrict inbound IP addresses

Along with Shared Access Signature (SAS), you might want to specifically limit the clients that can call your logic app. For example, if you manage your request endpoint by using Azure API Management, you can restrict your logic app to accept requests only from the IP address for the API Management instance.

Restrict inbound IP ranges in Azure portal

  1. In the Azure portal, open your logic app in the Logic App Designer.

  2. On your logic app's menu, under Settings, select Workflow settings.

  3. Under Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.

  4. Under IP ranges for triggers, specify the IP address ranges that the trigger accepts.

    A valid IP range uses these formats: x.x.x.x/x or x.x.x.x-x.x.x.x

If you want your logic app to trigger only as a nested logic app, from the Allowed inbound IP addresses list, select Only other Logic Apps. This option writes an empty array to your logic app resource. That way, only calls from the Logic Apps service (parent logic apps) can trigger the nested logic app.

Note

Regardless of IP address, you can still run a logic app that has a request-based trigger by using /triggers/<trigger-name>/run through the Azure REST API or through API Management. However, this scenario still requires authentication against the Azure REST API. All events appear in the Azure Audit Log. Make sure that you set access control policies accordingly.

Restrict inbound IP ranges in Azure Resource Manager template

If you automate deployment for logic apps by using Resource Manager templates, you can specify the IP ranges by using the accessControl section with the triggers section in your logic app's resource definition, for example:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

Add Azure Active Directory OAuth or other security

To add more authorization protocols to your logic app, consider using the Azure API Management service. This service helps you expose your logic app as an API and offers rich monitoring, security, policy, and documentation for any endpoint. API Management can expose a public or private endpoint for your logic app. To authorize access to this endpoint, you can use Azure Active Directory OAuth, client certificate, or other security standards for authorizing access to that endpoint. When API Management receives a request, the service sends the request to your logic app, also making any necessary transformations or restrictions along the way. To let only API Management trigger your logic app, you can use your logic app's inbound IP range settings.

Access to logic app operations

You can permit only specific users or groups to run specific tasks, such as managing, editing, and viewing logic apps. To control their permissions, use Azure Role-Based Access Control (RBAC) so that you can assign customized or built-in roles to the members in your Azure subscription:

To prevent others from changing or deleting your logic app, you can use Azure Resource Lock. This capability prevents others from changing or deleting production resources.

Access to run history data

During a logic app run, all the data is encrypted during transit by using Transport Layer Security (TLS) and at rest. When your logic app finishes running, you can view the history for that run, including the steps that ran along with the status, duration, inputs, and outputs for each action. This rich detail provides insight into how your logic app ran and where you might start troubleshooting any problems that arise.

When you view your logic app's run history, Logic Apps authenticates your access and then provides links to the inputs and outputs for the requests and responses for each run. However, for actions that handle any passwords, secrets, keys, or other sensitive information, you want to prevent others from viewing and accessing that data. For example, if your logic app gets a secret from Azure Key Vault to use when authenticating an HTTP action, you want to hide that secret from view.

To control access to the inputs and outputs in your logic app's run history, you have these options:

Restrict access by IP address range

You can limit access to the inputs and outputs in your logic app's run history so that only requests from specific IP address ranges can view that data. For example, to block anyone from accessing inputs and outputs, specify an IP address range such as 0.0.0.0-0.0.0.0. Only a person with administrator permissions can remove this restriction, which provides the possibility for "just-in-time" access to your logic app's data. You can specify the IP ranges to restrict either by using the Azure portal or in an Azure Resource Manager template that you use for logic app deployment.

Restrict IP ranges in Azure portal

  1. In the Azure portal, open your logic app in the Logic App Designer.

  2. On your logic app's menu, under Settings, select Workflow settings.

  3. Under Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.

  4. Under IP ranges for contents, specify the IP address ranges that can access content from inputs and outputs.

    A valid IP range uses these formats: x.x.x.x/x or x.x.x.x-x.x.x.x

Restrict IP ranges in Azure Resource Manager template

If you automate deployment for logic apps by using Resource Manager templates, you can specify the IP ranges by using the accessControl section with the contents section in your logic app's resource definition, for example:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "contents": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

Hide data from run history by using obfuscation

Many triggers and actions have settings to hide inputs, outputs, or both from a logic app's run history. Here are some considerations to review when you use these settings to secure this data.

Secure inputs and outputs in the designer

  1. In the Azure portal, open your logic app in the Logic App Designer.

    Open logic app in Logic App Designer

  2. On the trigger or action where you want to secure data, select the ellipses (...) button, and then select Settings.

    Open trigger or action settings

  3. Turn on either Secure Inputs, Secure Outputs, or both. When you're finished, select Done.

    Turn on secure inputs or outputs

    The action or trigger now shows a lock icon in the title bar.

    Action or trigger title bar shows lock icon

    Tokens that represent secured outputs from previous actions also show lock icons. For example, when you select such an output from the dynamic content list to use in an action, that token shows a lock icon.

    Select token for secured output

  4. After the logic app runs, you can view the history for that run.

    1. On the logic app's Overview pane, select the run that you want to view.

    2. On the Logic app run pane, expand the actions that you want to review.

      If you chose to secure both inputs and outputs, those values now appear hidden.

      Hidden inputs and outputs in run history

Secure inputs and outputs in code view

In the underlying trigger or action definition, add or update the runtimeConfiguration.secureData.properties array with either or both of these values:

  • "inputs": Secures inputs in run history.
  • "outputs": Secures outputs in run history.

Here are some considerations to review when you use these settings to secure this data.

"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Considerations when hiding inputs and outputs

  • When you secure the inputs or outputs on a trigger or action, Logic Apps doesn't send the secured data to Azure Log Analytics. Also, you can't add tracked properties to that trigger or action for monitoring.

  • The Logic Apps API for handling workflow history doesn't return secured outputs.

  • To secure outputs from an action that secures inputs or explicitly uses secured outputs, manually turn on Secure Outputs in that action.

  • Make sure that you turn on Secure Inputs or Secure Outputs in downstream actions where you expect the run history to secure that data.

    Secure Outputs setting

    When you manually turn on Secure Outputs in a trigger or action, Logic Apps secures these outputs in the run history. If a downstream action explicitly uses these secured outputs as inputs, Logic Apps hides this action's inputs in the run history, but doesn't enable the action's Secure Inputs setting.

    Secured outputs as inputs and downstream impact on most actions

    The Compose, Parse JSON, and Response actions has only the Secure Inputs setting. When turned on, the setting also hides these actions' outputs. If these actions explicitly use the upstream secured outputs as inputs, Logic Apps hides these actions' inputs and outputs, but doesn't enable these actions' Secure Inputs setting. If a downstream action explicitly uses the hidden outputs from the Compose, Parse JSON, or Response actions as inputs, Logic Apps doesn't hide this downstream action's inputs or outputs.

    Secured outputs as inputs with downstream impact on specific actions

    Secure Inputs setting

    When you manually turn on Secure Inputs in a trigger or action, Logic Apps secures these inputs in the run history. If a downstream action explicitly uses the visible outputs from that trigger or action as inputs, Logic Apps hides this downstream action's inputs in the run history, but doesn't enable Secure Inputs in this action and doesn't hide this action's outputs.

    Secured inputs and downstream impact on most actions

    If the Compose, Parse JSON, and Response actions explicitly use the visible outputs from the trigger or action that has the secured inputs, Logic Apps hides these actions' inputs and outputs, but doesn't enable these action's Secure Inputs setting. If a downstream action explicitly uses the hidden outputs from the Compose, Parse JSON, or Response actions as inputs, Logic Apps doesn't hide this downstream action's inputs or outputs.

    Secured inputs and downstream impact on specific actions

Access to parameter inputs

If you deploy across different environments, consider parameterizing the values in your workflow definition that vary based on those environments. That way, you can avoid hard-coded data by using an Azure Resource Manager template to deploy your logic app, protect sensitive data by defining secured parameters, and pass that data as separate inputs through the template's parameters by using a parameter file.

For example, if you authenticate HTTP actions with Azure Active Directory OAuth, you can define and secure the parameters that accept the client ID and client secret that are used for authentication. To define these parameters in your logic app, use the parameters section in your logic app's workflow definition and Resource Manager template for deployment. To hide parameter values that you don't want shown when editing your logic app or viewing run history, define the parameters by using the securestring or secureobject type and use encoding as necessary. Parameters that have this type aren't returned with the resource definition and aren't accessible when viewing the resource after deployment. To access these parameter values during runtime, use the @parameters('<parameter-name>') expression inside your workflow definition. This expression is evaluated only at runtime and is described by the Workflow Definition Language.

Note

If you use a parameter in a request header or body, that parameter might be visible when you view your logic app's run history and outgoing HTTP request. Make sure that you also set your content access policies accordingly. You can also use obfuscation to hide inputs and outputs in your run history. Authorization headers are never visible through inputs or outputs. So if a secret is used there, that secret isn't retrievable.

For more information, see these sections in this topic:

If you automate deployment for logic apps by using Resource Manager templates, you can define secured template parameters, which are evaluated at deployment, by using the securestring and secureobject types. To define template parameters, use your template's top level parameters section, which is separate and different from your workflow definition's parameters section. To provide the values for template parameters, use a separate parameter file.

For example, if you use secrets, you can define and use secured template parameters that retrieve those secrets from Azure Key Vault at deployment. You can then reference the key vault and secret in your parameter file. For more information, see these topics:

Secure parameters in workflow definitions

To protect sensitive information in your logic app's workflow definition, use secured parameters so this information isn't visible after you save your logic app. For example, suppose you have an HTTP action requires basic authentication, which uses a username and password. In the workflow definition, the parameters section defines the basicAuthPasswordParam and basicAuthUsernameParam parameters by using the securestring type. The action definition then references these parameters in the authentication section.

"definition": {
   "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
   "actions": {
      "HTTP": {
         "type": "Http",
         "inputs": {
            "method": "GET",
            "uri": "https://www.microsoft.com",
            "authentication": {
               "type": "Basic",
               "username": "@parameters('basicAuthUsernameParam')",
               "password": "@parameters('basicAuthPasswordParam')"
            }
         },
         "runAfter": {}
      }
   },
   "parameters": {
      "basicAuthPasswordParam": {
         "type": "securestring"
      },
      "basicAuthUsernameParam": {
         "type": "securestring"
      }
   },
   "triggers": {
      "manual": {
         "type": "Request",
         "kind": "Http",
         "inputs": {
            "schema": {}
         }
      }
   },
   "contentVersion": "1.0.0.0",
   "outputs": {}
}

Secure parameters in Azure Resource Manager templates

A Resource Manager template for a logic app has multiple parameters sections. To protect passwords, keys, secrets, and other sensitive information, define secured parameters at the template level and workflow definition level by using the securestring or secureobject type. You can then store these values in Azure Key Vault and use the parameter file to reference the key vault and secret. Your template then retrieves that information at deployment. For more information, see Pass sensitive values at deployment by using Azure Key Vault.

Here is more information about these parameters sections:

  • At the template's top level, a parameters section defines the parameters for the values that the template uses at deployment. For example, these values can include connection strings for a specific deployment environment. You can then store these values in a separate parameter file, which makes changing these values easier.

  • Inside your logic app's resource definition, but outside your workflow definition, a parameters section specifies the values for your workflow definition's parameters. In this section, you can assign these values by using template expressions that reference your template's parameters. These expressions are evaluated at deployment.

  • Inside your workflow definition, a parameters section defines the parameters that your logic app uses at runtime. You can then reference these parameters inside your logic app's workflow by using workflow definition expressions, which are evaluated at runtime.

This example template that has multiple secured parameter definitions that use the securestring type:

Parameter name Description
TemplatePasswordParam A template parameter that accepts a password that is then passed to the workflow definition's basicAuthPasswordParam parameter
TemplateUsernameParam A template parameter that accepts a username that is then passed to the workflow definition's basicAuthUserNameParam parameter
basicAuthPasswordParam A workflow definition parameter that accepts the password for basic authentication in an HTTP action
basicAuthUserNameParam A workflow definition parameter that accepts the username for basic authentication in an HTTP action
{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "LogicAppName": {
         "type": "string",
         "minLength": 1,
         "maxLength": 80,
         "metadata": {
            "description": "Name of the Logic App."
         }
      },
      "TemplatePasswordParam": {
         "type": "securestring"
      },
      "TemplateUsernameParam": {
         "type": "securestring"
      },
      "LogicAppLocation": {
         "type": "string",
         "defaultValue": "[resourceGroup().location]",
         "allowedValues": [
            "[resourceGroup().location]",
            "eastasia",
            "southeastasia",
            "centralus",
            "eastus",
            "eastus2",
            "westus",
            "northcentralus",
            "southcentralus",
            "northeurope",
            "westeurope",
            "japanwest",
            "japaneast",
            "brazilsouth",
            "australiaeast",
            "australiasoutheast",
            "southindia",
            "centralindia",
            "westindia",
            "canadacentral",
            "canadaeast",
            "uksouth",
            "ukwest",
            "westcentralus",
            "westus2"
         ],
         "metadata": {
            "description": "Location of the Logic App."
         }
      }
   },
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-0601/workflowdefinition.json#",
               "actions": {
                  "HTTP": {
                     "type": "Http",
                     "inputs": {
                        "method": "GET",
                        "uri": "https://www.microsoft.com",
                        "authentication": {
                           "type": "Basic",
                           "username": "@parameters('basicAuthUsernameParam')",
                           "password": "@parameters('basicAuthPasswordParam')"
                        }
                     },
                  "runAfter": {}
                  }
               },
               "parameters": {
                  "basicAuthPasswordParam": {
                     "type": "securestring"
                  },
                  "basicAuthUsernameParam": {
                     "type": "securestring"
                  }
               },
               "triggers": {
                  "manual": {
                     "type": "Request",
                     "kind": "Http",
                     "inputs": {
                        "schema": {}
                     }
                  }
               },
               "contentVersion": "1.0.0.0",
               "outputs": {}
            },
            "parameters": {
               "basicAuthPasswordParam": {
                  "value": "[parameters('TemplatePasswordParam')]"
               },
               "basicAuthUsernameParam": {
                  "value": "[parameters('TemplateUsernameParam')]"
               }
            }
         }
      }
   ],
   "outputs": {}
}

Access to services and systems called from logic apps

Here are some ways that you can secure endpoints that receive calls or requests from your logic app:

  • Add authentication to outbound requests.

    When you work with an HTTP-based trigger or action that makes outbound calls, such as HTTP, HTTP + Swagger, or Webhook, you can add authentication to the request that's sent by your logic app. For example, you can use these authentication types:

    For more information, see Add authentication to outbound calls later in this topic.

  • Restrict access from logic app IP addresses.

    All calls to endpoints from logic apps originate from specific designated IP addresses that are based on your logic apps' regions. You can add filtering that accepts requests only from those IP addresses. To get these IP addresses, see Limits and configuration for Azure Logic Apps.

  • Secure connections to on-premises systems.

    Azure Logic Apps provides integration with these services for secure and reliable on-premises communication.

    • On-premises data gateway

      Many managed connectors in Azure Logic Apps provide secure connections to on-premises systems, such as File System, SQL, SharePoint, and DB2. The gateway sends data from on-premises sources on encrypted channels through the Azure Service Bus. All traffic originates as secure outbound traffic from the gateway agent. Learn how the on-premises data gateway works.

    • Connect through Azure API Management

      Azure API Management provides on-premises connection options, such as site-to-site virtual private network and ExpressRoute integration for secured proxy and communication to on-premises systems. From your logic app's workflow in the Logic App Designer, you can select an API that's exposed by API Management, which provides quick access to on-premises systems.

Add authentication to outbound calls

HTTP and HTTPS endpoints support various kinds of authentication. Based on the trigger or action that you use to make outbound calls or requests that access these endpoints, you can select from varying ranges of authentication types. To make sure that you protect any sensitive information that your logic app handles, use secured parameters and encode data as necessary. For more information about using and securing parameters, see Access to parameter inputs.

Authentication type Supported by
Basic Azure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Client Certificate Azure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth Azure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Raw Azure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Managed identity (system-assigned only) Azure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook

Note

In the Logic App Designer, the Authentication property might be hidden on some triggers and actions where you can specify the authentication type. To make the property appear in these cases, on the trigger or action, open the Add new parameter list, and select Authentication. For more information, see Authenticate access with managed identity.

Basic authentication

If the Basic option is available, specify these property values:

Property (designer) Property (JSON) Required Value Description
Authentication type Yes Basic The authentication type to use
Username username Yes <user-name> The user name for authenticating access to the target service endpoint
Password password Yes <password> The password for authenticating access to the target service endpoint

When you use secured parameters to handle and protect sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. This example HTTP action definition specifies the authentication type as Basic and uses the parameters() function to get the parameter values:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Basic",
         "username": "@parameters('userNameParam')",
         "password": "@parameters('passwordParam')"
      }
  },
  "runAfter": {}
}

Client Certificate authentication

If the Client Certificate option is available, specify these property values:

Property (designer) Property (JSON) Required Value Description
Authentication type Yes Client Certificate
or
ClientCertificate
The authentication type to use for Secure Sockets Layer (SSL) client certificates. While self-signed certificates are supported, self-signed certificates for SSL aren't supported.
Pfx pfx Yes <encoded-pfx-file-content> The base64-encoded content from a Personal Information Exchange (PFX) file

To convert the PFX file into base64-encoded format, you can use PowerShell by following these steps:

1. Save the certificate content into a variable:

$pfx_cert = get-content 'c:\certificate.pfx' -Encoding Byte

2. Convert the certificate content by using the ToBase64String() function and save that content to a text file:

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

Password password See description <password-for-pfx-file> The password for accessing the PFX file.

Note: This property value is required when you work in the Logic App Designer and is not required when you work in code view.

When you use secured parameters to handle and protect sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. This example HTTP action definition specifies the authentication type as ClientCertificate and uses the parameters() function to get the parameter values:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ClientCertificate",
         "pfx": "@parameters('pfxParam')",
         "password": "@parameters('passwordParam')"
      }
   },
   "runAfter": {}
}

For more information about securing services by using client certificate authentication, see these topics:

Azure Active Directory OAuth authentication

If the Active Directory OAuth option is available, specify these property values:

Property (designer) Property (JSON) Required Value Description
Authentication type Yes Active Directory OAuth
or
ActiveDirectoryOAuth
The authentication type to use. Logic Apps currently follows the OAuth 2.0 protocol.
Tenant tenant Yes <tenant-ID> The tenant ID for the Azure AD tenant
Audience audience Yes <resource-to-authorize> The resource that you want to use for authorization, for example, https://management.core.windows.net/
Client ID clientId Yes <client-ID> The client ID for the app requesting authorization
Credential Type credentialType Yes Certificate
or
Secret
The credential type that the client uses for requesting authorization. This property and value don't appear in your logic app's underlying definition, but determines the properties that appear for the selected credential type.
Secret secret Yes, but only for the "Secret" credential type <client-secret> The client secret for requesting authorization
Pfx pfx Yes, but only for the "Certificate" credential type <encoded-pfx-file-content> The base64-encoded content from a Personal Information Exchange (PFX) file
Password password Yes, but only for the "Certificate" credential type <password-for-pfx-file> The password for accessing the PFX file
Authority authority No <URL-for-authority-token-issuer> The URL for the authority that provides the authentication token. By default, this value is https://login.windows.net.

Note: To make this property visible in the designer, on the trigger or action, open the Add new parameter list, and select Authority.

When you use secured parameters to handle and protect sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. This example HTTP action definition specifies the authentication type as ActiveDirectoryOAuth, the credential type as Secret, and uses the parameters() function to get the parameter values:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ActiveDirectoryOAuth",
         "tenant": "@parameters('tenantIdParam')",
         "audience": "https://management.core.windows.net/",
         "clientId": "@parameters('clientIdParam')",
         "credentialType": "Secret",
         "secret": "@parameters('secretParam')"
     }
   },
   "runAfter": {}
}

Raw authentication

If the Raw option is available, you can use this authentication type when you have to use authentication schemes that don't follow the OAuth 2.0 protocol. With this type, you manually create the authorization header value that you send with the outgoing request, and specify that header value in your trigger or action.

For example, here is a sample header for an HTTPS request that follows the OAuth 1.0 protocol:

Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

In the trigger or action that supports raw authentication, specify these property values:

Property (designer) Property (JSON) Required Value Description
Authentication type Yes Raw The authentication type to use
Value value Yes <authorization-header-value> The authorization header value to use for authentication

When you use secured parameters to handle and protect sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. This example HTTP action definition specifies the authentication type as Raw, and uses the parameters() function to get the parameter values:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Raw",
         "value": "@parameters('authHeaderParam')"
      }
   },
   "runAfter": {}
}

Managed identity authentication

If the Managed Identity option is available, your logic app can use the system-assigned identity for authenticating access to resources in other Azure Active Directory (Azure AD) tenants without signing in. Azure manages this identity for you and helps secure your credentials because you don't have to provide or rotate secrets. Learn more about Azure services that support managed identities for Azure AD authentication.

  1. Before your logic app can use the system-assigned identity, follow the steps in Authenticate access to Azure resources by using managed identities in Azure Logic Apps. These steps enable the managed identity on your logic app and set up that identity's access to the target Azure resource.

  2. Before an Azure function can use the system-assigned identity, first enable authentication for Azure functions.

  3. In the trigger or action where you want to use the managed identity, specify these property values:

    Property (designer) Property (JSON) Required Value Description
    Authentication type Yes Managed Identity
    or
    ManagedServiceIdentity
    The authentication type to use
    Audience audience Yes <target-resource-ID> The resource ID for the target resource that you want to access.

    For example, https://storage.azure.com/ makes the access tokens for authentication valid for all storage accounts. However, you can also specify a root service URL, such as https://fabrikamstorageaccount.blob.core.windows.net for a specific storage account.

    Note: This property might be hidden in some triggers or actions. To make this property visible, in the trigger or action, open the Add new parameter list, and select Audience.

    Important: Make sure that this target resource ID exactly matches the value that Azure AD expects, including any required trailing slashes. So, the https://storage.azure.com/ 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. To find these resource IDs, see Azure services that support Azure AD.

    When you use secured parameters to handle and protect sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. This example HTTP action definition specifies the authentication type as ManagedServiceIdentity and uses the parameters() function to get the parameter values:

    "HTTP": {
       "type": "Http",
       "inputs": {
          "method": "GET",
          "uri": "@parameters('endpointUrlParam')",
          "authentication": {
             "type": "ManagedServiceIdentity",
             "audience": "https://management.azure.com/"
          },
       },
       "runAfter": {}
    }
    

Next steps