How to Implement API-to-API Authentication in AKS using Azure Workload Identity?

I am currently exploring Microsoft Workload Identity to authenticate between two APIs deployed in Azure Kubernetes Service (AKS). Here's the scenario:

Provider API: A protected API that exposes data. Consumer API: Another API that calls the Provider API to fetch the data. Currently, I can implement this using the Client Credentials Flow by leveraging App Registrations with a client ID and client secret. However, I want to transition to Azure Workload Identity for authentication. While exploring, I encountered the following questions and challenges:

Do I still need App Registrations? Since both Managed Identities and App Registrations are essentially Service Principals, I am wondering if App Registrations are necessary if I use a User-Assigned Managed Identity for each application. Would having both Managed Identities and App Registrations result in two Service Principals for one API? Can I achieve this setup purely using Managed Identities without App Registrations?

How does it work without App Registrations? If I avoid App Registrations, how would the authentication work? Most of the documentation I’ve found focuses on enabling an Azure API to access Azure resources like Key Vault, but I couldn’t find clear examples or guides for API-to-API authentication in AKS using Managed Identity. Are there any resources or examples for this specific use case?

How to handle local development? For AKS, I can link the Service Account to the Managed Identity, but how can I simulate this setup for local development? Specifically, I need to debug both APIs locally and ensure end-to-end functionality. What would the recommended approach be for development environments?

Any relevant guidance, documentation links, or examples for achieving API-to-API authentication in AKS using Azure Workload Identity would be greatly appreciated.

Thank you!

Note that: To use managed identity, you need to deploy your code to any of the Azure resource (web app, function app, VMs etc) as managed identity do not work on local environment.

• As you mentioned that, you want to simulate this setup for local development you have to make use of Microsoft Entra ID applications as Managed identity will not work locally.
• Managed identities are primarily designed to be used with Azure resources to authenticate without needing explicit credentials like client IDs and secrets.

If you are calling the API with custom scope, then you cannot create the custom scope under managed identity. Only Azure resources scope can be defined directly.

• To grant custom scope to managed identity, you have to create an App registration -> Create scope -> Use PowerShell script to grant the custom scope to managed identity but this again requires the creation of managed identity. Refer this SO Thread by me.
• Hence in your scenario, if you are using custom API and custom scope you need to leverage Microsoft Entra applications only.

To achieve authentication with managed identity you still will be needing app registration where in you can create the custom scope and grant that scope to the managed identity like below:

For sample, I created one app registration and created an app role:

Now grant this permission to the managed identity:

Connect-MgGraph

New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId "APIAppServicePrincipalObjectId" -PrincipalId "managedIdentityObjectId" -ResourceId "APIAppServicePrincipalObjectId" -AppRoleId "appRoleId"

The managed identity will be granted the API permission:

Now generate the access token using the managed identity and call the API.

• If you are calling any other Azure Resource API such are Microsoft Graph API, then without creating an application you can directly assign permissions.
• As you are using custom API and custom scope/role you need to have app registration too.
• Managed identities can be used to authenticate and call an API but it has its own limitations and process based on the scenarios.