API Usage in Flow: Guide for Entra ID Authentication

Exploring API Usage in Flow with Entra ID Authentication: Summary by Timo Pertilä

Using APIs in Flow sometimes requires authentication when no ready-made connector is available. Most APIs require Entra ID (formerly Azure AD) authentication. The following options illustrate different ways to integrate Entra ID authentication into Flow whilst utilizing Power BI API as an example.

The first option uses the HTTP action and the Service Principal, identifying ourselves not as a user but as an application registered in Entra ID. Despite its advantages, the application's secret might be easily discovered by others and not all endpoints can be used with it.

The second option uses HTTP action with user authentication. Although an API can be used when identifying oneself as a user, the flow knows both the secret of the application and the user's password which can pose security issues. Also, a token cannot be generated if Multi-Factor Authentication (MFA) is enabled.

The third option involves packaging the API as a custom connector, defining also the authentication part. While doing so, it's critical to bear in mind that the custom connector requires maintenance and its connection may expire.

The fourth option utilizes Power Platform's HTTP with Azure AD connector for making API calls to Microsoft services using Entra ID as an authentication method. This option stands out due to its simplified processes and versatile advantages. Nevertheless, poor documentation and not working with all APIs and endpoints are some limitations.

The two primary options for using APIs in Flow are through HTTP action and Service Principal, or, HTTP action with the user. In the first scenario, identification happens at an application level, implying one would identify as the application itself as opposed to a user. An authorization token is generated with Flow for the application registered in Azure and this token is used for authentication.

• Pros:
  • Use of user password by Flow is eliminated making it invisible to others
  • Some endpoints only work with application-level rights
• Cons:
  • If the application secret is stored in the flow or used with the Keyvault action, it can be easily discovered by other creators
  • All endpoints cannot be used with the application as delegated user rights authentication is required
  • The application's secret expires with time and hence, should be updated in Flow
  • Registration in Azure is required

In the second scenario, logging into the Azure application takes place as a user instead of as an application, utilizing the access rights delegated to the application.

• Pros:
  • Useful when an API cannot be used as an application should identifying occur as a user
• Cons:
  • Both the application's secret and the user's password are visible to Flow
  • Token generation may not be possible if the user has MFA enabled

Apart from these options, there are various APIs that can be used with the method mentioned in option four, provided that the resource is found in Azure.

However, ready-made connectors available with a Power Automate license should not be overlooked. Flow has standard connectors that can be used to make calls to limited parts of Microsoft’s Graph API. Unfortunately, a corresponding connector for Power BI API is not available.

Read the full article Using an API in Flow with Entra ID authentication

Keywords

API Flow, Entra ID authentication, API implementation, API authentication, API integration, Flow API usage, Entra ID in API, API security, Flow API integration, Entra ID validation