Locking Down a Logic App (Consumption) with OAuth for Calls from Dataverse Plug-ins using Managed Identity

Locking Down a Logic App (Consumption) with OAuth for Calls from Dataverse Plug-ins using Managed Identity

Why I did this

I’m using managed identity to let a Dataverse plug-in call Azure resources without storing secrets. One of those calls hits a Logic App (Consumption) via the When an HTTP request is received trigger. I wanted to ensure the workflow can only be invoked by callers from my tenant using OAuth—no shared access signature (SAS) keys. (If you’re on Logic Apps Standard, you’d typically use App Service “Easy Auth”.)

Microsoft’s docs say you can require OAuth and (critically) you must disable SAS for request triggers in Consumption, otherwise a valid SAS bypasses OAuth. The official instructions work, but I found a simpler way to flip the SAS switch directly in code view.

What I changed

1) Disable SAS for the HTTP trigger (Consumption only)

image
  1. Open the Logic App (Consumption) in the Azure portal.
  2. Go to Development Tools ➜ Logic app code view.
  3. In the workflow JSON, add the following sibling to "parameters" (top level) and Save:
"accessControl": {
  "triggers": {
    "sasAuthenticationPolicy": {
      "state": "Disabled"
    }
  }
}

This disables SAS so OAuth can’t be bypassed. (This is equivalent to what the docs recommend; adding it here is the fastest way.)

⚠️ Important:

  • After you save, the accessControl snippet will not appear again the next time you open code view. The setting still applies, it’s just hidden.
  • If you try to reapply the JSON snippet again later, it will delete your existing OAuth profile, and you’ll need to recreate it from scratch.

Tip: If you automate deployments, include this in your ARM/Bicep/Template spec rather than patching after the fact.

2) Add an OAuth policy on the Logic App

image

  1. In the Logic App, go to Authorization.

  2. Click + Add policy ➜ OAuth 2.0.

  3. Enter:

    • Issuer (iss): use your tenant issuer, e.g.
      https://sts.windows.net/<tenant-guid>/ (v1) or
      https://login.microsoftonline.com/<tenant-id>/v2.0 (v2)
    • Audience (aud): the resource your token targets. In my case, I used https://management.azure.com.

  4. Save.

The OAuth policy validates the token’s iss and aud claims on inbound calls to the request trigger.

Narrowing Down the OAuth To Specific Managed Identity

If you want to ensure that only a specific managed identity can access this logic app you can additional add a custom claim onto the OAuth profile. To do this add a custom claim in the OAuth Profile. Set the claim name as appid and set the value to the id of your managed identity. This will ensure that only that managed identity can call this Logic App. You can add multiple OAuth profiles to allow for more managed identities if you want.

image

What broke (and how I fixed it)

On first run I got issuer or audience mismatch errors. My Dataverse plug-in was acquiring a token whose issuer looked like:

  • https://sts.windows.net/<tenant-guid>/ (AAD v1 style)

…but I had configured the Logic App policy with:

  • https://login.microsoftonline.com/<tenant-id>/ (different issuer format)

To debug, I had my plug-in log the raw access token, then pasted it into https://jwt.ms to inspect the claims. I updated the Logic App policy to use the exact issuer from the token, and everything worked.

Quick refresher:

  • Issuer (iss) must match exactly, including trailing slash and version (v1 vs v2.0).
  • Audience (aud) must match the resource you requested when you got the token (e.g., https://management.azure.com for ARM).

Minimal plug-in tracing snippet (to see the token)

When you call your Logic App from the plug-in, capture and trace the bearer token you’re sending. For example:

// inside Execute(IServiceProvider serviceProvider)
var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
var tracing = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

// Acquire the token with managed identity
string accessToken = context.ManagedIdentityService.AcquireToken("https://management.azure.com");

// Output the full token (needed for jwt.ms inspection)
tracing.Trace("AccessToken: {0}", accessToken);

// …then send HTTP request with Authorization: Bearer {accessToken}

⚠️ Note: Output the entire token (not truncated) if you want to paste it into jwt.ms for inspection of iss and aud. Also make sure to remove this tracing before deployment.

References

Comments

Post a Comment

Popular posts from this blog

Add User As Local Administrator On Domain Controller

I recently was settting up a new Microsoft SharePoint 2010 machine and had promoted the machine to a domain controller before creating my SharePoint admin accounts.  I needed to add several of my accounts to the local Administrators group.  Unfortunately after you promote a server to a domain controller you can no longer access the GUI for Local Users and Groups.  Instead I had to use the command line to add the users. Open a command promt using the "Run as administrator" function and then run the following command. net localgroup Administrators /add {domain}\{user} Note: do not include the {} brackets.
Read more

How to Create SharePoint Items with Power Automate Desktop

Image
Overview Power Automate Desktop is a great way to automate many of your daily task so you can focus on real work. A prime example of this is getting data from one place to another, especially when those data sources do not have an API such as a legacy desktop application or a file. In this example I demonstrate several ways in which an Excel sheet containing fictitious customer data could be loaded into a SharePoint list. In order to do this I first generated some fake data for my customers using Mockaroo . I then created a new SharePoint list and added some columns to match my spreadsheet. Methods My original plan was to just use the PAD recorder , which I did, but after creating that Flow I decided to find other possible ways to accomplish the task. The list below is not a complete list but should provide some ideas. The flexibility of PAD allows for an even wider range of possibilities for carrying out tasks such as these. At the end of each section I have placed the s...
Read more

Harnessing Host Form Data with PCF Controls in Model-Driven Applications

Image
Introduction This tutorial delves into integrating PowerApps Component Framework (PCF) controls with host form data within Microsoft Power Platform’s model-driven apps. This article will guide you through the necessary scripting to expose and consume formContext and globalContext from a custom table called new_Competitor. Aimed at enhancing both custom and Microsoft Form Component PCF controls, this approach ensures dynamic interactions with the host form data. Disclaimer : It’s important to note that there are various methods to retrieve data within PCF controls, including the use of WebAPI. While WebAPI provides a versatile way to access data across different entities and contexts, the approach described in this tutorial focuses on directly integrating with host form data, which can be particularly beneficial in specific use cases where immediate context is crucial. This method allows for real-time data interactions that are essential for certain scenarios, providing a streamlined...
Read more