Managed identity-based authorization leverages OAuth 2.0 as its underlying framework. This approach enhances both manageability and security by eliminating the need to store credentials. Moreover, OAuth tokens, unlike SAS tokens, have built-in expiration mechanisms, adding an extra layer of security to the authorization process.
When a component can be called only from one other component, you can check for the objectId of the caller. This is the oid attribute in the bearer token.
Example: One Logic App is called by one specific Logic App
In this example, a Logic App is always called by a specific Logic App. In the Authorization policy, you can check the caller by verifying the object ID of the managed identity (oid claim) as follows:
When a component can be called by multiple components, you have to check for different object IDs. However this becomes difficult to manage if this list is not fixed or different in different environments. For example, the list of managed identities might be different in Test and Production. To solve this, you can assign a User Assigned Managed Identity instead of a System Assigned Managed Identity. Multiple components can share the same User Assigned Managed Identity, so you can still validate the ObjectID.
One drawback of this approach is that the developer can assign the User Assigned Managed Identity to any component. This means that the developer authorizes the component. In some cases, you may want to restrict access to specific (verified) components.
Example 2: An API is called by multiple Logic Apps
For example, a customer has an API which returns confidential information. Access should therefore be restricted to specific Logic Apps. The policy of the API checks for specific object IDs.
A better way of doing this is to assign a role to a managed identity and validate against the role instead of a specific ObjectID. This is a well-hidden feature in the Microsoft documentation.
To do this, create an App Registration in Entra ID, and then an AppRole.
Then create an Application ID URI for this App Registration. You can use a default URI or create your own unique URI.
Now you must grant this role to the managed identities able to access this API. This is the quirky part: the portal will not allow you to assign a service principal to a managed identity, so you must do this with PowerShell as follows:
NOTE: Microsoft recommends using New-MgServicePrincipalAppRoleAssignment, but this method requires further permissions.
Although you cannot assign the permission, you can view it in the portal in the Permissions tab of the managed identity.
In the calling Logic App, authenticate with Managed Identity and set the Audience to the Application ID URI of App Registration. The latter is required to include the role claim in the OAuth token.
In the APIM policy, check if the role is present in the token.
TIP: In API Management, you can log the Authorization header and base64 decode the token. You can then inspect the claims included in the token.
Thanks to Pim Simons and René Bik, who pointed me in the right direction with this blog post. And thanks for reading!
Subscribe to our RSS feed