I want to make authenticated HTTP Requests to Graph API or Azure REST API from Power Automate. The standard way seems to be to create an App Registration (the identity basically) and enter its details under the “Active Directory OAuth” section of the “Authentication” drop down in the HTTP connector.
That is a lot of work. I’d have to involve the Azure AD admin (me in this case, and I know how lazy I am 😆) and store the secret or certificate to connect in a Key Vault etc… am too lazy for all that! 😊
I remember a colleague making Graph API calls via the HTTP connector using an authenticated connection, and I am sure I didn’t have to setup anything for hm. Checking with him I learnt he was using this connector:
Ah ha! Interesting. Sure enough, I can sign in to this connector and then it will use the identity of the signed in account to do Graph API calls. It sounds like this will only do Groups Graph API calls, but I tested it with a bunch of other endpoints (Graph and Azure REST API) and got this error:
|
1 |
URI path is not a valid Graph endpoint, path is neither absolute nor relative or resource is not one of the supported (me, users, groups, sites, search, planner, teams, chats) |
Good! So you can use this against a bunch of Graph API end points, not just the Groups one. Doesn’t help with Azure REST API but this is good in itself.
Looking around the list of HTTP connectors I found another one that might be useful for Azure REST API:
That asks for the following info when connecting:
I was looking into this for Key Vaults actually, so thought let me focus on that.
Inititally I filled it with the base Url of the Key Vault and set the Azure AD Resource URI as “KeyVault”. This is what I had done in the past when using the Get-AzAccessToken cmdlet but that gave me the error below:
After some trial and error I figured out the correct combo (ignore the error message, I took screenshots beforehand):
(Note: “https://vault.azure.net” is important. One time I used “https://vault.azure.net/” instead and that threw an error: “AKV10022: Invalid audience. Expected https://vault.azure.net, found: https://vault.azure.net/.“).
Clicking “Sign in” now brings up a page to login. I logged in and now we get the following (I renamed the connector, hence the different name in the screenshot):
I filled it in with an API call to get a secret. Standard stuff.
The first time it didn’t work as the account I was using didn’t have access to the Key Vault (which is good, proves that it works!) so I went to the Key Vault, granted the account Get secret access, ran the above, and it worked:
That’s nifty! This means I can make Azure REST API calls from Power Automate (and Power Apps etc. too I presume) using the HTTP with Azure AD connector. Here’s how I write to a Key Vault for instance (something the default connectors can’t do):
Power Automate + Logic Apps (or Azure Functions)
Even better the above means I can also authenticate against Azure Functions or Logic Apps etc. with Azure AD authentication. I had blogged in the past about using Azure AD authentication with Azure Functions and Logic Apps and how to invoke an Azure Function from a Logic App using Azure AD authentication. Let’s see if I can invoke a Logic App from Power Automate in an authenticated way.
For this I created a Logic App that responds to an HTTP request and added an authorization policy that expects a user from my tenant. I kept it simple and went with just the mandatory Issuer claim. All I care about at this point is that the person making the request is authenticated with my tenant.
Initially I had created only the first policy (the Url needs to be has to be https://login.microsoftonline.com/<tenantId>). But that kept throwing the following error on the Power Automate side “One or more claims either missing or does not match with the open authentication access control policy.” until I realized it probably expects the sts.windows.net Url as the issuer. Turns out it does, Power Automate sends the Issuer claim as https://sts.windows.net/<tenantId>.
Here’s me making a request from Power Automate via the standard HTTP connector, with no authentication. Notice the Url to the Logic App is without its SAS key.
This gives the following expected error:
So I use the Azure AD HTTP one. Be sure to create a new connection for this with the correct details for the Logic App. In this case I filled the base Url from the Logic App Url (which changes per Logic App) and put the App ID as in the screenshot (I knew this from before, but you can find a list of all the claims sent to Logic Apps from this link).
And that’s it really. Now I can make an authenticated query:
And it works as expected:
Beautiful!
Additional Stuff as a reminder to myself
I had done this in the past for Azure Functions and Logic Apps. I wonder if there’s a way to get the username of the caller from the claims the Logic App gets from Power Automate.
First I modified the Logic App to send the headers it receives from Power Automate as a response:
Nothing of interest in the headers though. Then I remember I had to make a change in the Logic App definition. Did that and now the Logic App headers include an “Authorization: Bearer xxxx” header with the token. This token has the username and other details of the account I am using on Power Automate.