Securing Azure Logic App HTTP Triggers with Azure AD
In the past, I have discussed how you can restrict access to logic apps that have an HTTP Trigger by restricting IP addresses. That does add an additional layer of protection to the SAS key that is typically used to secure logic app endpoints. However, we do have another option and that is using Azure AD integration.
In this post, I will summarize the steps used to protect your logic app HTTP trigger using Azure AD. For additional details, please check out this companion video on YouTube: Securing Azure Logic App HTTP Triggers with Azure AD.
Step 1 – Create Azure Logic App (Consumption)
Within our logic app, include an HTTP trigger and a response action. For the purpose of this post, I will n include a simple Response Body.
Step 2 – Test logic app using Postman
Copy the URL from the logic app trigger by clicking the copy icon. Within Postman, create a new POST request and paste your URL in the address bar. Execute your request to ensure you receive a valid response.
Step 3 – Create 2 Azure App Registrations
We need to create 2 Azure App Registrations. The first one we create will be for our “Client”, the second will be for the “Service”. These app registrations are critical in our ability to authenticate with Azure AD.
For this Client app, we need to create a secret that will be used when generating a token.
We will now create an Azure App registration for our Service.
For our Service Azure app registration, we don’t need to create a secret, but we do need to create an Application ID URI and assign a scope.
We will also create an App role for our Service app. You can think of it much like a claim that will be part of our token that we receive. If we un-pack the token, we will see this app role. We can use this to further validate what functionality we want to expose to our client, if we want.
With our Service app configured, we now need to return to our Client app where we will provide it permissions to call our Service app.
Once our permissions have been added, an admin will need to provide consent for our Client app to call our Service app.
Step 4 – Update Service App’s Manifest
We will now update the Manifest for our Service App and increase the accessTokenAcceptedVersion property to 2. This is a newer version than the default version and will have an impact when we validate (in the logic app) the token that was received.
Step 5 – Add Azure AD Authorization to Logic App
Navigate to the logic app that you created in Step 1. From there, click on the Authorization link and then establish the following 2 claims:
Audience: < Your Service App Client ID GUID >
Step 6 – (Optional) Enable Authorization Headers in Run History Outputs
If you want to view your token within your run history, you need to enable a property in the logic app code view. Find your trigger and then add the following property:
Step 7 – Test Logic App
This will be a 2-step activity. The first activity will be to obtain a token using the Azure app registration information we previously created. The second activity will be calling our action logic app.
To get our token, we need to make a GET call to the following URL:
The content type for this request will be x-www-form-urlencoded and we need to provide the following Key-Value pairs.
If you have configured everything successful, an access_token should be returned that we will need in the next step.
We are ready to call our logic app. We will now create a Post request and use our logic apps URL (without SAS Key) as our URL. We will then set our Authorization to use a Bearer Token and use the token from our previous step. We can now run our logic app and should see our response.
In this post we discovered how we can use Azure AD to authenticate HTTP Trigger requests. Using this approach provides an additional layer of security and governance to the other options that we have access to.
As a reminder, this content is also available in video form which can be accessed here: Securing Azure Logic App HTTP Triggers with Azure AD