Using OAuth authentication for HTTP request triggers in Power Automate
Microsoft has recently announced a new capability to add OAuth authentication to HTTP request triggered workflows, adding an additional layer of security to those kind of workflows. In the past, it was possible to create a workflow that was triggered when an HTTP request was made to a specific URL, which could lead to some security issues.
Let’s have a look at the different options that we have when working with the HTTP connector.
No authentication – Anyone can trigger the workflow
This was the only option that we had when working with the Request trigger so far. Anyone could trigger the workflow if the URL, method, and needed parameters were provided. In the following sample, a workflows receives a parameter called “name” within the HTTP request, and search for users with that name in the tenant’s Entra ID, returning some information about those who matched it.
This could be created in any Power Platform environment as long as the HTTP connector is allowed in the environment and is not excluded by any DLP policy, and the maker has the right license to use it, being a potential thread for data leaks. If we test the workflow with a tool like Postman, the result is the following:
Therefore, if anybody knows the URL, method (POST) and parameters (name), a user could trigger the workflow from any system!
Authentication – Any user in my tenant
If we want to restrict who can trigger the workflow and only allow users from our tenant, we should choose this option, which is now the default when adding it.
The POST URL will be different than the one used with no authentication, and now if we try to trigger the workflow from Postman, we will get a 401 unauthorized error as it would be expected.
What do we have to do to authenticate any user in our tenant and trigger the workflow? First of all, we need to register an application in Microsoft Entra ID, following next steps:
- Register a client application in Microsoft Entra ID. In the next step we will need Tenant Id and Application Id.
- Create a new client secret (with the expiration you want). Be sure to write down the generated password as we will need it later!
- Add permissions to use the Microsoft Power Automate API access Microsoft Flow as signed in user.
As admin consent is required for that permission, we will need to request for it.
Once we have create the application registration, any user of our tenant can trigger the workflow providing the right parameters. In the following sample, we are going to trigger our workflow from another one using the HTTP action:
In the HTTP action we must specify that we are using Active Directory OAuth, and fill in some required fields: Tenant Id, Client Id, Credential Type, Secret and Audience. The audience field will depend on the type of cloud your tenant is hosted, and be sure to fill it as it is specified in the documentation.
Client Secret
Be careful with the client secret, as it is visible to anyone that has access to the workflow. The best practice would be to store the client secret in Azure Key Vault and use Power Automate connector to retrieve it in the same workflow. In any case, you also should take care of the client secret value expiration, as the workflow will throw an error as soon as the secret is expired.
Authentication – Specific users in my tenant
In this case we restrict to workflow to be triggered only by some specific users of our tenant, although the implementation is very similar to the previous one:
The user “Lisa” is the only one authorized to trigger the workflow. Therefore, if any other user tries to make an HTTP request to trigger the workflow, he or she will receive a 401 unauthorized error.
We can trigger the workflow the same way we did in the previous section, and the same security recommendation also applies: Client Secret should be stored in Azure Key Vault so it is not visible to any user that has access to the workflow.
Finally, we also recommend that you secure the inputs and outputs of the different actions within your workflows, protecting sensitive information.
Summary
The HTTP request connector provides great flexibility when designing workflows, as you can trigger those making a simple HTTP call from any system or application. Its main drawback has always been security, as they can be used for purposes other than those originally intended. Thanks to the new authentication capabilities of the HTTP connector, we can leverage its full potential to design workflows whereas we keep them secure.