Securing your HTTP triggered flow in Power Automate

This is a quick post for giving a response to a question that comes out in our latest Microsoft’s webcast about creating cloud-based workflows for Dynamics 365 Business Central.

In this training I’ve talked a lot about the “When an HTTP request is received” action in Power Automate (and on Azure Logic Apps too) and how it’s extremely important on many scenarios, first of all for starting a workflow from your Dynamics 365 Business Central extensions by simply raising an HTTP call to the flow endpoint.

During the demo, I’ve created a simple HTTP triggered workflow that receives a POST request with a JSON body containing the destination address, the subject and the body of the email and then sends an email. The workflow in Power Automate was created like the following:

The problem here is that the endpoint is “public”, that means that everyone that knows that endpoint can trigger your workflow. The endpoint is something like https://prod-104.westeurope.logic.azure.com/workflows/7cd766d123e84c16a9a8b6c423aeb70a/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=rG_OM6yEnEvX8UeEpvZG-8ywZURGon9HU7WJiqn12aa , so not easy to obtain, but that is. As standard, you don’t have the possibility to use “authorization keys” like you can do for example with Azure Functions.

Question was: can I control who can use my Power Automate workflow?

The answer is yes and you have at least three possibilities:

  1. Use your security token in the url
  2. Passing a security token in the header of the HTTP call
  3. Use Azure API Management

To use a security token (like Authorization Keys on Azure Functions) you can change your flow as follows:

As a first step, add a relative path to your HTTP trigger action and here insert a token variable (here called SecurityToken):

Then check the condition of the SecurityToken variable, that must match with your defined authorization key:

If the condition is YES (the incoming caller has passed the right security token) the email is sent and you will receive HTTP status 200. If the condition is not matching (wrong security token) you can return a HTTP 401 error as response (with a custom body message).

What happens now?

The url of your HTTP triggered workflow is changed in this way: https://prod-104.westeurope.logic.azure.com/workflows/7cd766d123e84c16a9a8b6c423aeb70a/triggers/manual/paths/invoke/SendMail/{SecurityToken}?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=rG_OM6yEnEvX8UeEpvZG-8ywZURGon9HU7WJiqn12aa

If you pass a valid security token, the workflow completes successfully:

If instead you’re passing an invalid security token, the workflow fails:

and you have an HTTP 401 error as response:

The second possible way is to pass the authorization key to the request header when calling your workflow.

In this case, you can do like the following:

Here, I parse the JSON header of the incoming request in order to extract the SecurityToken parameter and than act as in the previous sample.

The third way is using Azure API Management. This is in my opinion the most “production-ready” way of work. You can create an instance of Azure API Management and then import your Power Automate workflow (HTTP endpoint) by selecting Add a new API and then select Blank App. In the Create a blank API page, past the endpoint URL of your workflow:

When the endpoint is imported on Azure API Management, you can control everything for your HTTP-triggered workflow (you can analyze the incoming request, specify policies for authentication and access restriction and also define custom authentication policies):

2 Comments

  1. How are the first 2 options that different from the original http request without token?
    Not using a token, provides public exposure to the API in case the endpoint is known.

    Include an additional fixed security token in the url / header, wouldn’t that result in a similar risk if one would know the endpoint with the – unencrypted – token?

    I struggle with the same issue when using Azure Functions too. If the admin / host keys are known (since these are not encrypted either), you’re function is available to anyone with the endpoint too.

    Like

    1. Absolutely agree with you. While keys provide a default security mechanism, you may want to consider additional options to secure an HTTP endpoint in production. App Service authentication or API Management offers more robust security mechanisms for example.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.