#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.
- To call the API, use the following HTTP request:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2?api-version=2021-02-01 - 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.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.
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:{ "id": "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2", "name": "authsettingsV2", "type": "Microsoft.Web/sites/config", "location": "{locationOfLogicApp}", "tags": {}, "properties": { "platform": { "enabled": true, "runtimeVersion": "~1" }, "globalValidation": { "requireAuthentication": true, "unauthenticatedClientAction": "AllowAnonymous" }, "identityProviders": { "azureActiveDirectory": { "enabled": true, "registration": { "openIdIssuer": "{issuerId}", "clientId": "{clientId}" }, "login": { "disableWWWAuthenticate": false }, "validation": { "jwtClaimChecks": {}, "allowedAudiences": [ {audience1}, "{audience2}" ], "defaultAuthorizationPolicy": { "allowedPrincipals": { "identities": [ "{ObjectId of AAD app1}", "{ObjectId of AAD app2}" ] } } } }, "facebook": { "enabled": false, "registration": {}, "login": {} }, "gitHub": { "enabled": false, "registration": {}, "login": {} }, "google": { "enabled": false, "registration": {}, "login": {}, "validation": {} }, "twitter": { "enabled": false, "registration": {} }, "legacyMicrosoftAccount": { "enabled": false, "registration": {}, "login": {}, "validation": {} }, "apple": { "enabled": false, "registration": {}, "login": {} } }, "login": { "routes": {}, "tokenStore": { "enabled": false, "tokenRefreshExtensionHours": 72.0, "fileSystem": {}, "azureBlobStorage": {} }, "preserveUrlFragmentsForLogins": false, "cookieExpiration": { "convention": "FixedTime", "timeToExpiration": "08:00:00" }, "nonce": { "validateNonce": true, "nonceExpirationInterval": "00:05:00" } }, "httpSettings": { "requireHttps": true, "routes": { "apiPrefix": "/.auth" }, "forwardProxy": { "convention": "NoProxy" } } } }
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:
- The request should have a valid Authorization header with "Bearer" scheme and the "WEBSITE_AUTH_ENABLED" appsetting set to true on the logicapp.
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.
- 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.
Microsoft
