Using an API in Power Automate with Entra ID authentication

Sometimes with cloud flow, you have to do things for which there is no ready-made connector available. This is not a problem, because most modern services have an interface (API) that can also be used from the flow.

Like this.

The API can be completely open, in which case there is no need to worry about authentication. In most cases, however, you must authenticate yourself for using the API. Microsoft services use Entra ID (formerly known as Azure AD) authentication for this.

In this case, you identify yourself, either as a user or as an application, against Entra ID. Let’s look at how this can be done in different ways in Power Automate. I will use Power BI API as an example in this post.

(If you’re not experienced with calling APIs, read this quick tutorial to grasp the basic concepts needed: How to use an API in Power Automate.)

Option 1 – HTTP action and Service Principal

The first option is to use the HTTP action and utilize the Service Principal. So we don’t identify ourselves as a user but as an application registered in Entra ID.

Here is one detailed example of this.

In short, an authorization token is created with flow for the application registered in Azure.

The generated token is then used in the actual API call for authentication.

Good

• Flow doesn’t use the user’s password -> It is not visible to others
• Some of the endpoints work only with application-level rights

Bad

• If the secret of the application is stored in the flow or it is used with the Keyvault action, it can be easily dug out by other makers
• All endpoints can’t be used with the application (authentication with delegated user rights is required)
• The application’s secret expires sooner or later and you should remember to update it to Flow as well
• Requires application registration on Azure

Option 2 – Using the HTTP action with the user

In the next option, we log into the Azure application as a user. In this case, the delegated access rights defined for the application are used. In practice, we can’t do anything that the used user has no permission for.

The implementation is very similar to the previous one.

Good

• If an API can’t be used as an application, l you can make it work by identifying yourself as a user

Bad

• Flow not only knows the secret of the application but also the user’s password. Not good.
• A token cannot be generated if the user has MFA enabled (and why wouldn’t it be)
• Requires application registration in Azure

Option 3 – Custom Connector

What if the API can’t be used as an application and it’s not possible to create service account in the organization without MFA?

You can package the API as a custom connector, where you define also the authentication part.

Instructions can be found online again. For example: https://learn.microsoft.com/en-us/connectors/custom-connectors/azure-active-directory-authentication

Good

• Password is stored in the created connection and no one can dig it out for themselves
• Used user account can have MFA enabled

Bad

• Requires application registration in Azure
• You get your own connector to maintain
• The connection may expire

Option 4 – HTTP with Azure AD connector

This time I saved the treat for last. Surprisingly few are aware of Power Platform’s HTTP with Azure AD connector and its Invoke an HTTP request action. This is due to the connector’s poor documentation.

This connector can be used to make API calls to Microsoft services using Azure Entra ID as an authentication method.

And that’s what we’ve been doing here all along in different ways.

Let’s add an action to our workflow.

When creating a connection, you define which service (Base Resource URL) will be used with the connection. And this is where the citizen developer easily gets confused. Where on earth can I find the Azure AD Resource URL for, for example, Power BI’s API?

The easiest way to do it in a trendy way is with chatGPT.

That is, for the Power BI API, the values ​​are

• Base resource URL: https://api.powerbi.com
• Azure AD Resource URL: https://analysis.windows.net/powerbi/api

Press “Sign In” and log in. After this, you can make API calls to the service without any authentication hassle. It’s already been done.

Works!

Good

• The password of the used user is stored in the created connection, it cannot be dug out from there
• The user can have MFA enabled
• No need to register your own application in Azure
• An excellent alternative to using Microsoft’s own services

Bad

• Does not work with all APIs and not all endpoints
• Poor documentation. Just have to try to see if it works for needed endpoints.
• The connection may expire
• The connection contains information about which service the connection is used for. Impossible to see which connection is created for which service

What APIs can actually be used with this method? During the creation phase, the connection must be given the address of the resource to be used in Azure (Azure AD Resource URL). It is probably safe to assume that the resource must also be found in Azure. Good candidates can be browsed, for example, from the API-permissions section of the application to be registered.

By the way, the much-needed Azure AD Resource URL can also be found here.

Don’t forget ready-made connectors!

All the options mentioned above require the user to have a Power Automate license. They rely on premium connectors.

Flow also has standard connectors that can be used to make calls to limited parts of Microsoft’s Graph API.

These include, for example, the following.

Unfortunately, there is no corresponding connector for Power BI API, for example.