Authenticating to Azure AD protected APIs with Managed Identity — No Key Vault required

A common way of authenticating to APIs, such as Microsoft Graph, has been that you set up an application registration in Azure AD, and create a client secret or a certificate. Then you store that sensitive information in an Azure Key Vault and have your application fetch it from there using its managed identity. After that, you’d use that fetched piece of information for authenticating to the API in your code. But did you know that there’s also an alternative way, which allows us to skip creating the application registration, client secret/certificate, and Azure Key Vault entirely?

We can allow our applications to authenticate to Azure AD protected APIs directly with the application managed identity. We don’t need to have a client secret or a certificate, and we can get rid of the risk of those pieces of sensitive information getting leaked. Otherwise, it works seemingly the same way by allowing us to use APIs with application permissions; it is just more secure.

Managed identity is not a new feature, and I know a few people have already blogged about this topic in the past. Still, I continue to run into developers who are not familiar with this approach. Based on my experience, it is clear that this method requires more exposure, which is why I am here writing about it for you. I hope you’ll find this article useful, and love using managed identity for authenticating to Azure AD protected APIs just as much as I do.

What are Managed identities for Azure resources?

A managed identity allows an Azure-hosted app to access other Azure AD protected services without having to specify explicit credentials for authentication. When you enable the managed identity for your app, a service principal gets created for your application in Azure AD. You can then grant that principal varying levels of permissions to the Azure resources and APIs used by your application. When we do not need to use and store separate credentials, it automatically improves the security of our application.

“When you enable managed identity on your web app, Azure activates a separate token-granting REST service specifically for use by your app. Your app will request tokens from this service instead of directly from Azure Active Directory. Your app needs to use a secret to access this service, but that secret is injected into your app’s environment variables by App Service when it starts up. You don’t need to manage or store this secret value anywhere, and nothing outside of your app can access this secret or the managed identity token service endpoint.” [source]

Managed identity is available for many Azure resources, such as Azure Functions, Web Apps and Logic Apps. You can check the Microsoft documentation for a full and up-to-date list of all the resource types that support managed identities.

System assigned vs. User assigned managed identities

We have two different types of managed identities: system assigned and user-assigned. Both of them work pretty much the same way from the authentication perspective, but they are administered quite differently. Being able to make the correct decision between them based on your scenario can help you reduce administrative overhead.

A system-assigned managed identity is always tied to just that one resource where it is enabled. You then control the permissions for that application individually. This is the preferred approach if your apps need different roles for different services.

A user assigned managed identity is created as a separate Azure resource. It can then be given permissions to services and added to multiple different Azure resources. This is the preferred approach if several apps need the same permissions to the same services.

Note that you don’t necessarily need to choose to use just either a system assigned or a user-assigned managed identity. Depending on the Azure resource, you can often combine both and use multiple user-assigned managed identities. You should always follow the principle of least privilege, and plan the permissions of the identities to be as fine-grained as possible.

Enabling the managed identity for your Azure application

You can enable the system managed service identity for an Azure resource by going to its Identity blade, changing the Status to On and then hitting Save. After saving, you’ll see a GUID in the Object ID field. This is the ID of the managed service identity. You’ll need the ID for managing your app’s permissions.

Managing your app’s permissions to the API

A widespread approach has been to enable the managed identity so that your app can securely access sensitive information stored in an Azure Key Vault. We’d do this for, e.g., getting a client secret from the key vault for authenticating to Microsoft Graph. However, it is also possible for us to grant our application permissions directly to Microsoft Graph (and other APIs) with PowerShell, which essentially allows us to skip the whole Azure Key Vault step entirely. At the time of this writing, PowerShell is our only option for performing this task; there is no way to do it in the Azure Portal.

For managing your application’s permissions using PowerShell, you first need to install the Azure AD PowerShell module, if you have not yet done so. You can install the module by running Windows PowerShell as an administrator, and then executing command Install-Module AzureAD.

Before you run the scripts, replace the miObjectId variable value with the ID of your application managed identity. You can see the ID in the view where you enabled the feature.

Also, if you want to manage your application’s permissions to some other API than Microsoft Graph, replace the appId variable value with the ID of the other API. You can find the ID of the API in the Enterprise applications view in Azure AD. There, select All Applications as the Application type, and search for your API. Then copy the GUID from the Application ID column.

Adding permissions

You can use the following script for granting permissions to an Azure AD protected API for your Azure-hosted app that has managed identity enabled. Replace the permissionsToAdd variable value with the API permissions/roles your application requires.

Checking existing permissions

If you later need to check what permissions your app has to the API in question, you can do that with the following script. You can run this script without the administrator roles mentioned above.

Removing permissions

If your app no longer needs some of the permissions granted earlier, you can remove them individually with the following script.

Authenticating using the managed service identity

Here I have a couple of examples for you of how to use a managed identity for authentication in your solution. First, we have a .NET Core solution, and then I’ll show you how we can easily authenticate in an Azure Logic App using its managed identity. Again, I’m using Microsoft Graph as the API in both of these examples.

.NET Core

As the first thing, install the Microsoft.Azure.Services.AppAuthentication NuGet package to your project, and specify a matching using statement for your namespace: using Microsoft.Azure.Services.AppAuthentication;

The method below will get an access token for the specified API using the managed identity of the Azure resource where your app is running. The resourceUrl (the URL address of the API) is the only mandatory parameter. The second parameter appId should only be specified when you are using the user-assigned managed identity. When the second parameter is not provided, system-assigned managed identity will be used by default.

Azure Logic Apps

Calling an API in Azure Logic Apps with the HTTP action by using a managed identity is super easy. You first add either a system-assigned or a user-assigned managed identity for your app — just like you would for any other Azure resource. Then, while configuring the HTTP action, you select Managed Identity as the authentication type and select the identity from the dropdown. The only thing that requires a bit of typing regarding authentication is the Audience which is the URL of the API you want to call.

Afterword

So, what do you think of using managed identities for authentication? They are pretty awesome, eh? If you have any thoughts, comments or questions about the topic, feel free to write about them to me using the comments section below. I genuinely hope you enjoyed reading this article and found it useful.

Also, if you’d like to consume more content from me, feel free to subscribe to my Insider (news)letter and follow me on your favourite social media platforms (Twitter, YouTube, LinkedIn, Github). I share different types of content on each one of them.

Thank you for reading, it is always appreciated, and until next time!

Laura