MS Power Automate HTTP Request Action Authentication Types
How to tell your API friends on the internet they are allowed talk to you and your Flow.
In a different post I talked about MS Power Automate’s HTTP Request Action. In this post I will go into some more detail on the most common types of authentication that I have encountered and give some examples of how to use them.
Pre-requisites:
- Knowledge of the following concepts:
- HTTP Requests
- REST APIs
- Access to MSD365 Power Automate, MSD365 Office, MSD365 Business Central, MS Graph API, or any other REST API to connect to
- Knowledge of how to create an App Registration in Azure AD
I’m going to focus on the two most HTTP Authentication Protocols I have had to use:
- Basic (in various forms, I’m also including any id / key or token scenario here where the token is already known)
- Azure Active Directory / OAuth2.0
To view the authentication options for the MS Power Automate HTTP Request action click “Show Advanced Options” on the action card in the Flow:
Basic Authentication with the MS Power Automate HTTP Request Action
There are different flavors of “Basic” authentication, but they all boil down to passing an Id / Password pair. Usually, we will have to go and set the access key for a user and then we can use that access key to authenticate with the REST API. In this example I will use a “Personal Access Token” I generated for GitHub’s API.
All I need to do to setup this type of authentication is:
- Click “Show Advanced Options”
- Enter the username in the “Username” field
- Enter the Access Token in the “Password” field
That’s all I need to do. When this HTTP request executes my “username” and “password” (the Personal Access Token” I generated at the GitHub web site) will be sent and used as the authentication. Here is the raw input from the HTTP Request Action when the Flow is executed:
{
“uri”: “https://api.github.com/user/repos?=",
“method”: “GET”,
“authentication”: {
“username”: “*sanitized*”,
“password”: “*sanitized*”,
“type”: “Basic”
}
}
Sometimes, we need to finagle the Basic Authentication request to get it to work with the API we are trying to talk to; technically we may be interfacing with another authentication type but we have a token to use. For example, sometimes we need to set the “Authentication” field to “None” and put our authentication information in the Headers of the request. To do this we need to put the information in the “Header” fields of the MS Power Automate HTTP request action:
The below raw input from when this flow was ran show the difference in what was sent to the API:
{
“uri”: “https://{baseurl}/orders/{id}",
“method”: “GET”,
“headers”: {
“X-Auth-Token”: “*sanitized*”,
“Content-Type”: “application/json”,
“Accept”: “application/json”
}
}
With this flexibility we can handle many Basic type Authentication scenarios that come up.
I think it’s better to pass the API key in the header of the request when ever possible and always use HTTPS when sending an API key.
Azure Active Directory / Oauth2 Authentication with the MS Power Automate HTTP Request Action
Like with the Basic authentication, different endpoint will require some different settings to get the authentication to work with them. Unfortunately there isn't a one size fits all solution that works for every API. We usually have to tweak the settings to get the connection working, but for the most part it’s generally the same. For this example I will connect to the MS Graph API and list the groups in my MS Office 365 Tennant. If you are nor familiar with the MS Graph API definitely check it out. It provides an API endpoint to so many of the MSD365 services. You can explore the possibilities with the MS Graph Explorer. In order to connect to the MS Graph API, I need to create an Azure AD App Registration in the MS Office 365 tenant I want to use. From the Azure AD app registration, I will need the Client Id and Client Secret. For this post I will assume we already did that. I will make another post on how to make an Azure AD app registration.
The MS Graph API uses Azure Active Directory authentication, information on how to connect can be found here.
To connect to MS Graph API and get my group list I need to:
- Put the endpoint URL in the URI field
- Change the “Authentication” field to “Active Directory OAuth”
- Set the “Authority” field to “https://login.windows.net”
- Set the “Tenant” field to the value for the MS Office 365 tenant to use
- Set the “Audience” field to “https://graph.microsoft.com”
- Set the “Client ID” field to the client id of the Azure AD app registration.
- Set the “Credential Type” field to “Secret”
- Set the “Secret” field to the Client Secret of the Azure AD app registration.
The HTTP Request action will then take care of handling the OAuth2 flow to get the access token needed for this request and return us back the list of Groups in our tenant.
The raw input for the HTTP trigger after the Flow is run looks like this:
{
“uri”: “https://graph.microsoft.com/v1.0/groups",
“method”: “GET”,
“authentication”: {
“authority”: “https://login.windows.net",
“tenant”: “{tenant}”,
“audience”: “https://graph.microsoft.com",
“clientId”: “{client Id}”,
“secret”: “*sanitized*”,
“type”: “ActiveDirectoryOAuth”
}
}
It’s great how this action handles getting the token for us. In interfacing with other Oauth2 APIs I sometimes have not been able to get the authentication to work with the HTTP Request trigger and instead have created a Custom Connection in MS Power Automate to use. I will go over how to make a custom connection in another post.
There are a lot of different authentication scenarios we could encounter when interfacing with REST APIs using the MS Power Automate HTTP Request action. I went over two of the most common ones I have had to use. You will have to play around with the settings and the Headers to get different authentication types to work with different APIs.
