Power Automate HTTP triggered flows can in theory be called by any party that has the trigger URL, which can be retrieved from the flow trigger settings:-

The trigger URL includes a SAS signature as a querystring value, but other than that, the URL has anonymous access.

There are methods of providing better access control, but no official way, until a recent update from Microsoft announced the ability to secure calls to HTTP triggered flows using OAuth and restricting access to:

• Any user in the tenant
• Specific users in the tenant
• Anyone

➜ Something to be aware of is that, as you select different Who Can Trigger The Flow options, the trigger URL will change as follows:

• Choosing Anyone means that the trigger URL will include a SAS signature
• Choosing Any user in the tenant or Specific users in the tenant, means that the trigger URL will not include a SAS signature

Choosing Anyone is equivalent to the legacy setting before this update, and all existing HTTP triggered flows will continue to work as though this option were selected. If you edit an existing HTTP triggered flow, you will have to choose one of these options before saving.

Choosing Any user in the tenant or Specific users in the tenant, changes the flow so that it can only be triggered (called) by any tenant user or specific tenant users, and a valid OAuth bearer token must be provided in the HTTP headers of the flow trigger request.

POST https://<flow trigger URL> HTTP/1.1
Accept: application/json
Content-Type: application/json
Authorization: Bearer <eyJ0eXAiOiJKV...............mTEEuWxBOQva9V>

{}

The Bearer token provided must, at least, contain the following claims:-

• aud
  The audience of the flow service which varies depending on the cloud version, but for the public cloud this will be https://service.flow.microsoft.com/
  ➜ Note the trailing backslash – this is important
  ➜ See this link for audience values https://learn.microsoft.com/en-us/power-automate/oauth-authentication?tabs=classic-designer#audience-values
• iss
  The issuer of the access token and will typically be the token issuance authority of your Entra ID tenant
• tid
  This will be the tenant ID (GUID)
• oid
  The object id of the requestor; either the object id of the requesting application or the object id of the requesting user’s Entra account
  This claim is ignored unless you’ve configured the flow trigger to restrict to specific users in the tenant.

When choosing Specific users in the tenant, you also have to provide the email addresses of the specific user(s) who are allowed to call the flow:

Although the documentation doesn’t mention it, instead of email addresses you can instead supply a list of the oid values of the user accounts for the specific users who can call the flow:

Calling a Secure Flow from Another Flow

To call a secure flow from another flow, you can use the HTTP Request action configured to use Active Directory OAuth, and for this you’ll need to create an Entra ID App Registration – https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app

➜ For a HTTP triggered flow configured with Any user in the tenant, you must use the HTTP Request action because it acquires an application-only access token which doesn’t contain a user security context .

➜ For a HTTP triggered flow configured with Specific users in the tenant, you must use the HTTP with Microsoft Entra ID (preauthorized) action instead, because it acquires an user-delegated access token with a user security context of the user who creates the connection – though I’ve not managed to get this approach to work.

The only requirements for the app registration are a client id, secret, and permission grants for the flow service:-

For the permission grants, the resource is Power Automate and the permission grant required is https://service.flow.microsoft.com/User, which is a user delegated permission.

Once this is done and you’ve consented the App Registrations API permission grants, create a new flow which will be used to call a secured HTTP triggered flow, and add a HTTP Request action (this is a premium action):-

• Set the URI to the trigger URL of the flow to be called
• Set the method to POST
• Set the request headers and body as required for your flow
• Set the Authentication Type to Active Directory OAuth
• You can leave Authority blank
• Set the Tenant to your Entra ID tenant id
• Set the Audience to https://service.flow.microsoft.com/ but this may vary depending on the type of cloud (see the section above about the aud claim)
• Set the Client ID and Secret to the values from your App Registration

Calling a Secure Flow from PostMan

To call a secure flow from PostMan, first you’ll need to acquire an access token – you can do this natively using PostMan, or you can make a call to the Entra ID token issuance endpoint directly using a Client Credentials or ROPC (Resource Owner Password Credentials) grant.

In this example I’ll use an ROPC grant:

➜ The double backslash in the scope parameter is important and not a typo

Then using PostMan send the request to the flow:-

Calling a Secure Flow from SPFx

To call a secure flow from an SPFx customisation, first you’ll need to add the required flow service permission to your tenants SharePoint Online Client Extensibility Web Application Principal app registration/service principal – https://learn.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient.

You can do this directly using a CLI tool (see the above link) or by assigning the required permission grant requests to the webApiPermissionRequests property of your SPFx projects package-solution.json file, and approving the API permission request in the SharePoint Admin Centre once the solution has been deployed:-

You’d then use the SPFx context aadHttpClientFactory property to acquire an AadHttpClient which you can use to call the secured flow:-

Unauthorised Access

When a flow is configured for Any user in the tenant or Specific users in the tenant, and no access token is supplied, or the access token supplied doesn’t match the configuration of the trigger, or fails validation for any other reason, the client application or caller will get a standard HTTP 403 Forbidden response:-

References:

• https://powerautomate.microsoft.com/en-us/blog/deeper-control-over-http-invocation-of-flows/
• https://learn.microsoft.com/en-us/power-automate/oauth-authentication
• https://learn.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc