In yesterday’s blog post we started to look at the different types of permissions we can use to authorise against resources via Microsoft Graph using. This covered looking at both delegated permissions and application permissions. In this post, we’ll start to focus more closely on working with delegated permissions when interacting with the Microsoft Graph API. This post will cover the approaches we can use when using delegated permissions, and then over the next few days we’ll look at how to achieve these approaches when working with the Power Platform.
If you’re enjoying this content, covering Microsoft Graph and utilising the wider Microsoft Cloud ecosystem effectively to embed contextual data into your Low Code solutions, be sure to subscribe to my blog to get my latest articles directly in your inbox.
SubscribeHTTP Action in Power Automate – A Limitation
So yesterday we touched on why delegated permissions can be slightly more difficult to work with when interacting with the Microsoft Graph API, and that is because they require 2 things being the context of the user, as well as the application (client), to authorise access to the resource, in contrast to application permissions which only require the application (client) to be present.
The limitation that makes providing these 2 things, the context of the user, as well as the application, difficult, is that the HTTP connector in Power Automate lacks the capability to cache a users credentials to attach to the request towards the API.
This means we can only use single HTTP steps without previous steps to capture an access token, if we’re working with application permissions.
Just because application permissions are now easier to work with, by only using application permissions and not doing extra work to capture user context, do not take this approach for cases where it is technically possible to use delegated permissions.
We can overcome this limitation however, by utilising one of the methods of working with delegated permissions in this blog post.
Building a custom connector
My preferred method to achieving authorisation when working with delegated permissions against the Microsoft Graph API, is to build a custom connector. I personally find this method easier to achieve, and also provides some other benefits.
- Better quality where a single connector provides the foundations for multiple actions and calls across a solution or multiple solutions.
- Reusability where the actions can just simply be selected in a flow or called using Power Fx in a canvas app removing the need to solve the authentication part of an API call when building solutions.
- Ease of use for makers where lower level makers might not be comfortable working with the HTTP step to interact with custom APIs, or they might not be able to build custom connectors, but they would be more comfortable implementing actions from a custom connector that a more senior developer has engineered.
- Power Apps and Power Automate can both take advantage of a custom connector we build rather than only Power Automate having the ability to make HTTP actions easily out the box.
We’ll take a look at how to build a custom connector to interact with the Microsoft Graph API, utilising delegated permissions in tomorrow’s blog post.
2 Step HTTP Action in Power Automate
The next option we have to authorise access to resources using delegate permissions when working with the Power Platform is a two step approach with HTTP actions in Power Automate.
When working with the Microsoft Graph API, in order to authenticate and authorise access to resource, our application makes an authentication request towards the Microsoft identity platform to retrieve an access token. This access token can hold details about the application, but also details about the user in delegated scenarios.
Simply using a single HTTP action and then authentication using our application doesn’t capture user context and provide an access token from the Microsoft identity platform which contains that information about the user.
So, in order to work with delegated permissions against Microsoft Graph when using the HTTP step in Power Automate, we need to make two requests.
Our first request will be a POST request towards the Microsoft identity service with a base url of https://login.microsoftonline.com
This first call towards that API will capture our token which we will need to pull out of an object returned in the response body.
Then to authenticate against the request to Microsoft Graph we actually want to make, we will add this access token as a Bearer token to the authorisation header in our final HTTP step.
We will look at how to achieve this, in a step by step post coming in a few days time following the first approach above.
Invoke a HTTP request – with Azure AD
The third option we have available is using the Invoke an HTTP request with Azure AD in Power Automate. This step handles authentication for us and hence is a lot more simple to work with.
We can simply add an Invoke an HTTP request step to our flow and specify https://graph.microsoft.com in both the Base Resource URL and the Azure AD Resource URI, which handles our authentication for delegated permissions cases, then finally we can simply use the action to make calls towards the Graph API without even having to specify further authentication details about an app registration.
We will look more closely at this approach in a few days following articles on the two approaches above.
Subsequent content
Now check out the content published following this post covering step by step guides to the methods above.