This guide outlines the process for assigning application roles to a Managed Identity (MI) in Entra ID. It covers observed behaviors, inherent limitations, and the necessary steps required when an MI must authenticate with another application (such as an API in APIM) using role-based access control (RBAC).

Scenario

In a typical architecture, a Logic App utilizes a Managed Identity (either System-Assigned or User-Assigned) to communicate with downstream resources. When that Logic App needs to call an API exposed via APIM, the following requirements usually apply:

  • The API is protected by its own App Registration in Entra ID.
  • The API expects the caller to possess specific app roles (e.g., API.Read or API.ReadWrite).
  • The Logic App must obtain an OAuth token containing these roles to successfully authorize against the API.

The Challenge

Managed Identities are automatically created Service Principals. A common point of confusion is that they do not appear in the App Registration section of the Azure portal; they are found exclusively under Enterprise Applications.

Because the Azure portal does not currently provide a UI for assigning app roles to Enterprise Applications directly, it is not possible to assign roles like API.Read through the standard “API Permissions” blade used for traditional App Registrations.

The Workaround — Assigning App Roles via PowerShell / Microsoft Graph

You can use the below Powershell to assign roles to your Managed Identity

# Install-Module Microsoft.Graph -Scope CurrentUser (If not done already)

# Your tenant ID (in the Azure portal, under Azure Active Directory > Overview).
$tenantID = ‘{tenantId}’

# The name of the server app that exposes the app roles.
$serverApplicationName = ‘{serverApplicationName}’

# The name of the app role that the managed identity should be assigned to.
$appRoleName = ‘{appRoleName}’ # For example, Api.Read

# Look up the Logic App / Function (Client application) managed identity’s object ID.
$managedIdentityObjectId = ‘{managedIdentityObjectId}’

# Connect-MgGraph -TenantId $tenantId -Scopes ‘Application.ReadWrite.All’,‘Directory.Read.All’
# or a more restricted set of permissions (recommended):
Connect-MgGraph -TenantId $tenantId -Scopes ‘Application.Read.All’,‘AppRoleAssignment.ReadWrite.All’

# Look up the details about the server app’s service principal and app role.
$serverServicePrincipal = (Get-MgServicePrincipal -Filter “DisplayName eq ‘$serverApplicationName’”)
$serverServicePrincipalObjectId = $serverServicePrincipal.Id
$appRoleId = ($serverServicePrincipal.AppRoles | Where-Object {$_.Value -eq $appRoleName }).Id

Write-Host ‘$serverServicePrincipal ’ $serverServicePrincipal
Write-Host ‘$managedIdentityObjectId ’ $managedIdentityObjectId
Write-Host ‘$serverServicePrincipalObjectId ’ $serverServicePrincipalObjectId
Write-Host ‘AppRoleId >’ $appRoleId

# Assign the managed identity access to the app role.
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $serverServicePrincipalObjectId -PrincipalId $managedIdentityObjectId -ResourceId $serverServicePrincipalObjectId -AppRoleId $appRoleId

  • PrincipalId → Managed Identity object ID (Logic App)
  • ResourceId → API service principal object ID
  • AppRoleId → GUID of the role defined in the API registration

After this assignment, tokens requested by the Managed Identity will include the required roles claim, allowing successful authorization against the API.

Note

  • For clientId to be able to be used as an audience it must “own” App Roles. And the consumer-client-id should have been provided this roles in AAD. I think you can further check these claims in the Authentication section

Key Takeaways

  • Managed Identities always appear as Enterprise Apps in Azure AD.
  • App roles cannot be assigned via the portal for Enterprise Apps; Graph / PowerShell is required.
  • Token validation depends on correct Issuer, Audience, and presence of role claims.
  • Explicit role assignment ensures tokens carry the required roles for API authorization.