What is the difference between HTTP with Microsoft Entra ID and HTTP with Microsoft Entra ID (preauthorized) connectors?

A year ago, I reviewed how some of Microsoft’s APIs can be used within Power Automate by the HTTP with Azure AD connector. This is often really handy:

• The API is utilized with delegated access rights
• The password is stored in the created connection, it cannot be dug out from there
• Used account can have MFA enabled
• No need to register an application in Azure AD

In the same story, I compared different ways to call the API (provided by Microsoft) that uses Entra ID authentication

• Using HTTP action with Service Principal
• Using HTTP action with user
• Custom connector
• HTTP with Azure AD connector

After renaming the Azure AD, the HTTP with Azure AD connector disappeared and was replaced by HTTP with Microsoft Entra ID connector. But there are now two of them. Standard and preauthorized.

What is the difference between these two connectors? Let’s find out.

HTTP with Microsoft Entra ID (preauthorized)

HTTP with Microsoft Entra ID (preauthorized) is practically the same as the old HTTP with Azure AD connector. With it you can use (with delegated permissions) various Microsoft services (Microsoft Graph API, Dataverse API, Power BI API, etc.). You do not need to make any configuration for Entra ID (register the application or define authorizations). The connector is already authorized to use selected services of certain APIs.

Example – List Teams I am a member of

Let’s make a flow that uses the Microsoft Graph API to retrieve information about the teams I’m a member of. The Invoke an HTTP request action of the HTTP with Microsoft Entra ID (preauthorized) connector is added to Flow.

When creating a connection, the addresses of the resource to be used are defined. In our example, the Microsoft Graph API.

The generated connection reference does not tell which service it was created for.

This easily causes problems in the future when you try to figure out which connection reference you can use to use the Microsoft Graph API and which to use the Power BI API etc. It is worth adding the service you are using to the name of the connection reference.

Finally, a call is made that returns the teams I am a member of.

https://graph.microsoft.com/v1.0/me/joinedTeams

And here are the results.

Example – Presence of users

The problem with a preauthorized connector is that not all endpoints of the API are available. We are trying to retrieve the presence information of person x.

https://graph.microsoft.com/v1.0/communications/getPresencesByUserId

No luck. The preauthorized connector has no permission to do that.

With Graph Explorer, we can see that such an endpoint exists and it works for the user we are using.

Now, the second version of the connector comes into play.

HTTP with Microsoft Entra ID

The connector is used in the same way as the preauthorized version. But this version is not pre-approved to use any services.

The Invoke an HTTP request function of the HTTP with Microsoft Entra ID connector is added to flow.

Let’s define again which service is used (Microsoft Graph API).

We can’t even create a connection. Because no permissions have been defined for the connector.

Example – Presence of users

We want to retrieve people’s presence data from the Microsoft Graph API. It didn’t work with the preauthorized connector, so let’s authorize this other one and use it.

Authorizing the connector

For now, authorization can only be done with Power Shell (version 7 or later). Let’s get the PowerShell script (ManagePermissionGrant.ps1) from GitHub. And turn on Unblock from the file settings.

Open PowerShell and connect.

Connect-MgGraph

We need to identify ourselves (with the admin account).

Run the ManagePermissionGrant.ps1 command. The Microsoft Graph API can be found under option A (Azure Global), so let’s select that one.

Once again, you identify yourself (with Global Admin), after which you can choose either from the most used applications (C) or from all (A).

We want to choose from all options, so we choose A. A dialog opens, from which the desired service is first selected. There’s quite a lot of services available here. Let’s choose Microsoft Graph.

We finally get to choose the endpoints of Microsoft Graph.

Now we need to check from the documentation which rights are required to apply for presence information.

Presence.Read.All is enough. Let’s add it.

Next, we selected whether all or only selected users can use selected endpoints with the connector. In this example we give permission to everyone.

Confirm and authorization is done.

Although authorizations cannot be made from the Azure portal, they are visible there. Let’s search for the application HttpWithAADApp and look at its permissions.

Here they are.

Use of connector

Now we can add Invoke an HTTP request function of the HTTP with Microsoft Entra ID connector into the flow.

We still use the Microsoft Graph API, so we give its URLs on creation.

We are trying to retrieve the user’s presence information.

And here they are!

Summary

The new connector (HTTP with Microsoft Entra ID) is a great addition. It allows you to use the endpoints of several Microsoft APIs within the end user’s permissions (delegated rights).

Handy, for example, when the API is used from Power Apps.

However, a few things should be noted.

1. Global Admin rights are required to authorize the connector
2. The connector has only one authorization setting. Selected users (or all users of the tenant) are allowed to use all endpoints authorized by it in all Power Platform environments

The use of the connector in different environments can be restricted by DLP policies. Unfortunately, endpoint-level DLP rules can only be made for the preauthorized version of the connector.