#Edits

June 18, 2024

The Easy Auth can be configured from UX on a Standard Logic App in the \"Authentication\" blade under the Settings group. Apps that already have Auth Settings V2 configured will also display the details in this blade.

Sample screenshot:

#EndEdits

For single-tenant Azure Logic Apps, we're adding the capability in Standard logic apps to set up Azure Active Directory (Azure AD) authorization policies. When a Standard logic app workflow starts with the Request trigger, which handles inbound HTTP calls, the logic app expects each received inbound request to present access tokens that include Azure AD policies. This authentication also permits requests for the location header from an asynchronous workflow. Similar to a Consumption logic app, you can specify the claim types and values that the logic app expects in the access token presented by each inbound request.

Sometimes called \"Easy Auth\", this capability is an Azure Functions provision for authenticating access with a managed identity and is available through Azure App Service's built-in authentication and authorization capabilities. Easy Auth makes authenticating workflow invocations possible through triggers. Rather than use Shared Access Signature (SAS) tokens, you can use Easy Auth as a more secure authentication method that doesn't require access token regeneration. Basically, Easy Auth provides all the advantages available when you use a managed identity for authentication. For more information, review Authentication and authorization in Azure App Service and Azure Functions.

Meanwhile, to set up authorization policies, you can call the Auth Settings V2 by using an HTTP client such as Postman. For more information about the Swagger description, review Auth Settings V2 - WebApps REST API. This article shows how to enable and use Easy Auth this way for authenticating calls sent to the Request trigger in a Standard logic app workflow.

Enable Easy Auth on the Request trigger

This section provides more information about calling the Auth Settings V2 API.

\n
1. To call the API, use the following HTTP request:
   
   \n

   PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2?api-version=2021-02-01

   \n
\n
2. When you call the Auth Settings V2 API, replace all the property placeholder values, such as {subscriptionId}, with the actual values you want to use. However, in the request body, keep the following properties unchanged:
   
   \"globalValidation\": {
      \"requireAuthentication\": true,
      \"unauthenticatedClientAction\": \"AllowAnonymous\"
   }
   Note- EasyAuth is managed by AppService, and for an incoming request, it is a hop that that comes before LA Runtime. When EasyAuth is enabled for a Logicapp standard, all incoming requests are validated against the policies in your V2 Auth settings.\n

    

   \n

   If you have “unauthenticatedClientAction”: “Return401” and when the request fails with EasyAuth, those requests are not routed to LA runtime and will fail with 401 from AppService. Therefore, you will also observe broken portal experience with Return401. When you set it to “AllowAnonymous”, all calls (failed and successful) will be routed to the LA runtime. The LA runtime will know if the request failed with EasyAuth or was successful and will process the request accordingly. For example, to get run histories, we authenticate it on SAS specific to that run generated based on the Logic Apps access keys. LA runtime will know that this request failed with EasyAuth but it will be processed successfully as it has valid SAS. The underlying AppService platform will have no knowledge of validating other auth like SAS.

   \n
   The following list has more information about the specific properties that you use:
   
   - identityProviders.azureActiveDirectory.openIdIssuer: The token issuer for your Azure AD
   - identityProviders.azureActiveDirectory.clientId: The ID for your AAD App Registration. This will be augmented as an allowed audience.
   - identityProviders.azureActiveDirectory.validation.allowedAudiences: An array with the allowed audience values for the token
   - identityProviders.azureActiveDirectory.validation.defaultAuthorizationPolicy.allowedPrincipals.identities: An array with the object IDs for the Azure AD identities, such as user/group
   
   The following example, which is attached at the end of this article, shows a sample payload to include as the PUT request body:
   

   {\n    \"id\": \"/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2\",\n    \"name\": \"authsettingsV2\",\n    \"type\": \"Microsoft.Web/sites/config\",\n    \"location\": \"{locationOfLogicApp}\",\n    \"tags\": {},\n    \"properties\": {\n        \"platform\": {\n            \"enabled\": true,\n            \"runtimeVersion\": \"~1\"\n        },\n        \"globalValidation\": {\n            \"requireAuthentication\": true,\n            \"unauthenticatedClientAction\": \"AllowAnonymous\"\n        },\n        \"identityProviders\": {\n            \"azureActiveDirectory\": {\n                \"enabled\": true,\n                \"registration\": {\n                    \"openIdIssuer\": \"{issuerId}\",\n                    \"clientId\": \"{clientId}\"\n                },\n                \"login\": {\n                    \"disableWWWAuthenticate\": false\n                },\n                \"validation\": {\n                    \"jwtClaimChecks\": {},\n                    \"allowedAudiences\": [\n                        {audience1},\n                        \"{audience2}\"\n                    ],\n                    \"defaultAuthorizationPolicy\": {\n                        \"allowedPrincipals\": {\n                            \"identities\": [\n                                \"{ObjectId of AAD app1}\",\n                                \"{ObjectId of AAD app2}\"\n                            ]\n                        }\n                    }\n                }\n            },\n            \"facebook\": {\n                \"enabled\": false,\n                \"registration\": {},\n                \"login\": {}\n            },\n            \"gitHub\": {\n                \"enabled\": false,\n                \"registration\": {},\n                \"login\": {}\n            },\n            \"google\": {\n                \"enabled\": false,\n                \"registration\": {},\n                \"login\": {},\n                \"validation\": {}\n            },\n            \"twitter\": {\n                \"enabled\": false,\n                \"registration\": {}\n            },\n            \"legacyMicrosoftAccount\": {\n                \"enabled\": false,\n                \"registration\": {},\n                \"login\": {},\n                \"validation\": {}\n            },\n            \"apple\": {\n                \"enabled\": false,\n                \"registration\": {},\n                \"login\": {}\n            }\n        },\n        \"login\": {\n            \"routes\": {},\n            \"tokenStore\": {\n                \"enabled\": false,\n                \"tokenRefreshExtensionHours\": 72.0,\n                \"fileSystem\": {},\n                \"azureBlobStorage\": {}\n            },\n            \"preserveUrlFragmentsForLogins\": false,\n            \"cookieExpiration\": {\n                \"convention\": \"FixedTime\",\n                \"timeToExpiration\": \"08:00:00\"\n            },\n            \"nonce\": {\n                \"validateNonce\": true,\n                \"nonceExpirationInterval\": \"00:05:00\"\n            }\n        },\n        \"httpSettings\": {\n            \"requireHttps\": true,\n            \"routes\": {\n                \"apiPrefix\": \"/.auth\"\n            },\n            \"forwardProxy\": {\n                \"convention\": \"NoProxy\"\n            }\n        }\n    }\n}​

   \n

    

   \n
\n

Call the Request trigger with Azure AD OAuth

To call the Request trigger in your workflow using Azure AD OAuth, send a request to the callback or invoke URL by passing the Authorization header, but not the SAS tokens, in the query parameter using the following syntax:

POST https://{logicAppName}.azurewebsites.net:443/api/{workflowName}/triggers/manual/invoke?api-version=2020-05-01-preview

For example, in your HTTP client, which is Postman here, make the following call:

Troubleshoot errors

If the following errors happen, try the suggested resolutions:

\n
• The request should have a valid Authorization header with \"Bearer\" scheme and the \"WEBSITE_AUTH_ENABLED\" appsetting set to true on the logicapp.
  
  \n

  This error means that your authentication token failed authorization. You can ignore the part about the \"WEBSITE_AUTH_ENABLED appsetting\" because you don't need to update this value on your logic app and is going to be fixed. Make sure that you've entered the necessary property values as specified in the Easy Auth setup section.

  \n

   

  \n
\n
• The request has both SAS authentication scheme and Bearer authorization scheme. Only one scheme should be used.
  
  You can't use both SAS and Bearer authorization scheme tokens at the same time. You can use only one token because both tokens are valid and cause confusion when calling the request trigger.
  
\n

#Edits

June 18, 2024

The Easy Auth can be configured from UX on a Standard Logic App in the \"Authentication\" blade under the Settings group. Apps that already have Auth Settings V2 configured will also display the details in this blade.

Sample screenshot:

#EndEdits

For single-tenant Azure Logic Apps, we're adding the capability in Standard logic apps to set up Azure Active Directory (Azure AD) authorization policies. When a Standard logic app workflow starts with the Request trigger, which handles inbound HTTP calls, the logic app expects each received inbound request to present access tokens that include Azure AD policies. This authentication also permits requests for the location header from an asynchronous workflow. Similar to a Consumption logic app, you can specify the claim types and values that the logic app expects in the access token presented by each inbound request.

Sometimes called \"Easy Auth\", this capability is an Azure Functions provision for authenticating access with a managed identity and is available through Azure App Service's built-in authentication and authorization capabilities. Easy Auth makes authenticating workflow invocations possible through triggers. Rather than use Shared Access Signature (SAS) tokens, you can use Easy Auth as a more secure authentication method that doesn't require access token regeneration. Basically, Easy Auth provides all the advantages available when you use a managed identity for authentication. For more information, review Authentication and authorization in Azure App Service and Azure Functions.

Meanwhile, to set up authorization policies, you can call the Auth Settings V2 by using an HTTP client such as Postman. For more information about the Swagger description, review Auth Settings V2 - WebApps REST API. This article shows how to enable and use Easy Auth this way for authenticating calls sent to the Request trigger in a Standard logic app workflow.

Enable Easy Auth on the Request trigger

This section provides more information about calling the Auth Settings V2 API.

\n
1. To call the API, use the following HTTP request:
   
   \n

   PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2?api-version=2021-02-01

   \n
\n
2. When you call the Auth Settings V2 API, replace all the property placeholder values, such as {subscriptionId}, with the actual values you want to use. However, in the request body, keep the following properties unchanged:
   
   \"globalValidation\": {
      \"requireAuthentication\": true,
      \"unauthenticatedClientAction\": \"AllowAnonymous\"
   }
   Note- EasyAuth is managed by AppService, and for an incoming request, it is a hop that that comes before LA Runtime. When EasyAuth is enabled for a Logicapp standard, all incoming requests are validated against the policies in your V2 Auth settings.\n

    

   \n

   If you have “unauthenticatedClientAction”: “Return401” and when the request fails with EasyAuth, those requests are not routed to LA runtime and will fail with 401 from AppService. Therefore, you will also observe broken portal experience with Return401. When you set it to “AllowAnonymous”, all calls (failed and successful) will be routed to the LA runtime. The LA runtime will know if the request failed with EasyAuth or was successful and will process the request accordingly. For example, to get run histories, we authenticate it on SAS specific to that run generated based on the Logic Apps access keys. LA runtime will know that this request failed with EasyAuth but it will be processed successfully as it has valid SAS. The underlying AppService platform will have no knowledge of validating other auth like SAS.

   \n
   The following list has more information about the specific properties that you use:
   
   - identityProviders.azureActiveDirectory.openIdIssuer: The token issuer for your Azure AD
   - identityProviders.azureActiveDirectory.clientId: The ID for your AAD App Registration. This will be augmented as an allowed audience.
   - identityProviders.azureActiveDirectory.validation.allowedAudiences: An array with the allowed audience values for the token
   - identityProviders.azureActiveDirectory.validation.defaultAuthorizationPolicy.allowedPrincipals.identities: An array with the object IDs for the Azure AD identities, such as user/group
   
   The following example, which is attached at the end of this article, shows a sample payload to include as the PUT request body:
   {\n \"id\": \"/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2\",\n \"name\": \"authsettingsV2\",\n \"type\": \"Microsoft.Web/sites/config\",\n \"location\": \"{locationOfLogicApp}\",\n \"tags\": {},\n \"properties\": {\n \"platform\": {\n \"enabled\": true,\n \"runtimeVersion\": \"~1\"\n },\n \"globalValidation\": {\n \"requireAuthentication\": true,\n \"unauthenticatedClientAction\": \"AllowAnonymous\"\n },\n \"identityProviders\": {\n \"azureActiveDirectory\": {\n \"enabled\": true,\n \"registration\": {\n \"openIdIssuer\": \"{issuerId}\",\n \"clientId\": \"{clientId}\"\n },\n \"login\": {\n \"disableWWWAuthenticate\": false\n },\n \"validation\": {\n \"jwtClaimChecks\": {},\n \"allowedAudiences\": [\n {audience1},\n \"{audience2}\"\n ],\n \"defaultAuthorizationPolicy\": {\n \"allowedPrincipals\": {\n \"identities\": [\n \"{ObjectId of AAD app1}\",\n \"{ObjectId of AAD app2}\"\n ]\n }\n }\n }\n },\n \"facebook\": {\n \"enabled\": false,\n \"registration\": {},\n \"login\": {}\n },\n \"gitHub\": {\n \"enabled\": false,\n \"registration\": {},\n \"login\": {}\n },\n \"google\": {\n \"enabled\": false,\n \"registration\": {},\n \"login\": {},\n \"validation\": {}\n },\n \"twitter\": {\n \"enabled\": false,\n \"registration\": {}\n },\n \"legacyMicrosoftAccount\": {\n \"enabled\": false,\n \"registration\": {},\n \"login\": {},\n \"validation\": {}\n },\n \"apple\": {\n \"enabled\": false,\n \"registration\": {},\n \"login\": {}\n }\n },\n \"login\": {\n \"routes\": {},\n \"tokenStore\": {\n \"enabled\": false,\n \"tokenRefreshExtensionHours\": 72.0,\n \"fileSystem\": {},\n \"azureBlobStorage\": {}\n },\n \"preserveUrlFragmentsForLogins\": false,\n \"cookieExpiration\": {\n \"convention\": \"FixedTime\",\n \"timeToExpiration\": \"08:00:00\"\n },\n \"nonce\": {\n \"validateNonce\": true,\n \"nonceExpirationInterval\": \"00:05:00\"\n }\n },\n \"httpSettings\": {\n \"requireHttps\": true,\n \"routes\": {\n \"apiPrefix\": \"/.auth\"\n },\n \"forwardProxy\": {\n \"convention\": \"NoProxy\"\n }\n }\n }\n}​\n

    

   \n
\n

Call the Request trigger with Azure AD OAuth

To call the Request trigger in your workflow using Azure AD OAuth, send a request to the callback or invoke URL by passing the Authorization header, but not the SAS tokens, in the query parameter using the following syntax:

POST https://{logicAppName}.azurewebsites.net:443/api/{workflowName}/triggers/manual/invoke?api-version=2020-05-01-preview

For example, in your HTTP client, which is Postman here, make the following call:

Troubleshoot errors

If the following errors happen, try the suggested resolutions:

\n
• The request should have a valid Authorization header with \"Bearer\" scheme and the \"WEBSITE_AUTH_ENABLED\" appsetting set to true on the logicapp.
  
  \n

  This error means that your authentication token failed authorization. You can ignore the part about the \"WEBSITE_AUTH_ENABLED appsetting\" because you don't need to update this value on your logic app and is going to be fixed. Make sure that you've entered the necessary property values as specified in the Easy Auth setup section.

  \n

   

  \n
\n
• The request has both SAS authentication scheme and Bearer authorization scheme. Only one scheme should be used.
  
  You can't use both SAS and Bearer authorization scheme tokens at the same time. You can use only one token because both tokens are valid and cause confusion when calling the request trigger.
  
\n

WadeMCG , There isn’t any documentation available for this at the moment (though it might be released soon). You can still use it if you’d like, and it does the two things I mentioned earlier.

AllowAnonymous doesn’t turn off EasyAuth, so I’m not sure how it defeats the purpose. It serves two purposes: it permits requests with a valid SAS and enables the runtime to return more detailed error messages if something goes wrong. Your app remains secure at all times. To achieve your goal, the best approach is to use EasyAuth with AllowAnonymous and set the SAS Authentication Policy State to Disabled.

How to Set the SAS Authentication Policy State to Disabled.

Can I please have some documentation on this? I don't really want to be fiddling with these sorts of settings without really knowing what they do and I can't find any documentation on any of it. Source code is fine or just something I can read. 

Failing that, my backup is to enforce that any HTTP request *did not* use the signature in the URL (Meaning the only way they managed to call was via EasyAuth). 

But again, I still don't see the point of enabling EasyAuth and then ticking the box that says AllowAnonymous. Doesn't that entirely defeat the point? 

WadeMCG ,

If the signature is leaked, then one can regenerate the access key which will invalidate all signatures that came from it.

I understand your need to be able to disable SAS auth for added security. There is a way to disable SAS on the triggers so you may invoke the trigger using EasyAuth only. Set this property on the Logic App Standard properties (peer to SiteConfig)in the PUT Site call:

\"logicAppsAccessControlConfiguration\": {\n    \"triggers\": {\n        \"sasAuthenticationPolicy\": {\n            \"State\": \"Disabled\"\n        }\n    }\n}

Note that this will disable SAS authentication for triggers invoke requests and will also return the callback URLs for all triggers like request trigger, webhooks without SAS. This won't invalidate the existing SAS. So, when the SAS Authentication Policy State is Enabled, those existing SAS will continue to work.

arjunchiddarwar 

I understand why it's necessary. My point is that I was under the assumption that we turn on utilizing something like Managed Identity, so that if the signature URL ever leaks, it doesn't allow unauthorized access. With how Microsoft have done EasyAuth for Logic Apps, it doesn't increase protection at all because if someone just simply doesn't use a bearer token (Or even has an invalid token), as long as they have the signature they can still call the app. 

So, the real question is. Why use EasyAuth at all? What does it give you when an attacker can just bypass it completely using the signature? The only possible benefit is that requests across the wire don't need to carry the signature now. But I think the chance of intercepting a request like this between two applications is relatively slim. 

WadeMCG, thanks for your feedback on this post.

This article seems to be referenced everywhere by Microsoft, but I'm actually slightly baffled that it's main flaw is not pointed out. 

If you do all of this to the letter in this article, if you do : 

>\"unauthenticatedClientAction\": \"AllowAnonymous\"

To allow access in the portal. Did anyone actually try then just using the Http Trigger, with no bearer auth, with the signature? It works just fine because sure the Easy Auth fails, but because we said go on through, if you have the signature it allows you to execute the logic app anyway. Surely the entire point of adding EasyAuth is that it is *enforced* and you must use it. Otherwise what's the point? 

arjunchiddarwar Thanks for this post. I tried setting up the Auth using the UX in the Azure Portal. I have a workflow that has a trigger \"When a HTTP request is received\". For some reason when I navigate to my Workflows, the Workflow URL is blank. 

I got a 200 with a \"Your Azure Function App is up and running.\" page when I tried to access the URL of the logic app which makes me believe that the Auth is setup correctly.

Now I just need to figure out what the exact url is to trigger the workflow. I tried the following and it gave me 404 Not Found:

1. POST https://<logic-app-name>.azurewebsites.net/api/test-workflow/triggers/manual/invoke

2. POST https://<logic-app-name>.azurewebsites.net/workflows/test-workflow/triggers/manual/run

Any ideas on:
1. Why the Workflow URL is blank? - possibly the root cause of the issue

2. What the Workflow URL should be given a workflow name

Update: I did set \"App Service Authentication Settings\" is set to \"Require authentication\" which causes the issue where you cannot access a lot of the Workflow fields in the Portal. The Workflow URL is 
https://<logic-app-name>.azurewebsites.net:443/api/test-workflow/triggers/When_a_HTTP_request_is_received/invoke?api-version=2022-05-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0

bpgva arjunchiddarwar I am getting same error message 

\"500 Unable to download OpenID Connect Configuration\" when I call the logic app trigger url.\" from postman with bearer token. any help would be great. Thanks

I am trying to trigger my logic app through Postman. What is the scope to set to get token ? 

When I use the scope https://graph.microsoft.com/.default and that I use the generated access token, I get the error message \"500 Unable to download OpenID Connect Configuration\" when I call the logic app trigger url.

Any idea on this?

Information for those arriving here after deploying the authconfigv2 via Bicep to the Standard Logic App and still getting 401 Unauthorized:

{
    \"error\": {
        \"code\": \"DirectApiInvalidAuthorizationScheme\",
        \"message\": \"The provided authorization token is not valid. The request should have a valid authorization header with 'Bearer' scheme.\"
    }
}

For some reason deploying that via Bicep will not enable the authentication so when trying to authenticate so you will still have to do the PUT operation via API to actually enable it...

EDIT:

Issue is solved after adding:

    platform: {
      enabled: true
      runtimeVersion: '~1'
    }

To the Bicep code.

https://github.com/Azure/bicep/issues/12220