Authenticate Azure-hosted apps to Azure resources with the Azure SDK for .NET

When an app is hosted in Azure using a service like Azure App Service, Azure Virtual Machines, or Azure Container Instances, the recommended approach to authenticating an app to Azure resources is to use a managed identity.

A managed identity provides an identity for your app such that it can connect to other Azure resources without the need to use a secret key or other application secret. Internally, Azure knows the identity of your app and what resources it's allowed to connect to. Azure uses this information to automatically obtain Microsoft Entra tokens for the app to allow it to connect to other Azure resources, all without you having to manage any application secrets.

Managed identity types

There are two types of managed identities:

• System-assigned - This type of managed identity is provided by and tied directly to an Azure resource. When you enable managed identity on an Azure resource, you get a system-assigned managed identity for that resource. A system-assigned managed identity is tied to the lifecycle of the Azure resource it's associated with. When the resource is deleted, Azure automatically deletes the identity for you. Since all you have to do is enable managed identity for the Azure resource hosting your code, this is the easiest type of managed identity to use.
• User-assigned - You may also create a managed identity as a standalone Azure resource. This is most frequently used when your solution has multiple workloads that run on multiple Azure resources that all need to share the same identity and same permissions. For example, if your solution had components that ran on multiple App Service and virtual machine instances that all needed access to the same set of Azure resources, creating and using a user-assigned managed identity across those resources would make sense.

This article will cover the steps to enable and use a system-assigned managed identity for an app. If you need to use a user-assigned managed identity, see the article Manage user-assigned managed identities to see how to create a user-assigned managed identity.

1 - Enable managed identity in the Azure resource hosting the app

The first step is to enable managed identity on Azure resource hosting your app. For example, if you're hosting a .NET app using Azure App Service, you need to enable managed identity for the App Service web app that is hosting your app. If you were using a virtual machine to host your app, you would enable your VM to use managed identity.

You can enable managed identity to be used for an Azure resource using either the Azure portal or the Azure CLI.

• Azure portal
• Azure CLI

Instructions	Screenshot
Navigate to the resource that hosts your application code in the Azure portal.For example, you can type the name of your resource in the search box at the top of the page and navigate to it by selecting it in the dialog box.
On the page for your resource, select the Identity menu item from the left-hand menu.All Azure resources capable of supporting managed identity will have an Identity menu item even though the layout of the menu may vary slightly.
On the Identity page: Change the Status slider to On. Select Save. A confirmation dialog will verify you want to enable managed identity for your service. Answer Yes and managed identity will be enabled for the Azure resource.

2 - Assign roles to the managed identity

Next, determine which roles (permissions) your app needs and assign the managed identity to those roles in Azure. A managed identity can be assigned roles at a resource, resource group, or subscription scope. This example will show how to assign roles at the resource group scope since most applications group all their Azure resources into a single resource group.

• Azure portal
• Azure CLI

Instructions	Screenshot
Locate the resource group for your app by searching for the resource group name using the search box at the top of the Azure portal. Navigate to your resource group by selecting the resource group name under the Resource Groups heading in the dialog box.
On the page for the resource group, select Access control (IAM) from the left-hand menu.
On the Access control (IAM) page: Select the Role assignments tab. Select + Add from the top menu and then Add role assignment from the resulting drop-down menu.
The Add role assignment page lists all of the roles that can be assigned for the resource group. Use the search box to filter the list to a more manageable size. This example shows how to filter for Storage Blob roles. Select the role that you want to assign. Select Next to go to the next screen.
The next Add role assignment page allows you to specify what user to assign the role to. Select Managed identity under Assign access to. Select + Select members under Members. A dialog box will open on the right-hand side of the Azure portal.
In the Select managed identities dialog: The Managed identity dropdown and Select text box can be used to filter the list of managed identities in your subscription. In this example, by selecting App Service, only managed identities associated with an App Service are displayed. Select the managed identity for the Azure resource hosting your app. Select Select at the bottom of the dialog to continue.
The managed identity will now show as selected on the Add role assignment screen. Select Review + assign to go to the final page and then Review + assign again to complete the process.

3 - Implement DefaultAzureCredential in your application

DefaultAzureCredential is an opinionated, ordered sequence of mechanisms for authenticating to Microsoft Entra ID. Each authentication mechanism is a class derived from the TokenCredential class and is known as a credential. At runtime, DefaultAzureCredential attempts to authenticate using the first credential. If that credential fails to acquire an access token, the next credential in the sequence is attempted, and so on, until an access token is successfully obtained. In this way, your app can use different credentials in different environments without writing environment-specific code.

To use DefaultAzureCredential, add the Azure.Identity and optionally the Microsoft.Extensions.Azure packages to your application:

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

Azure services are accessed using specialized client classes from the various Azure SDK client libraries. These classes and your own custom services should be registered so they can be accessed via dependency injection throughout your app. In Program.cs, complete the following steps to register a client class and DefaultAzureCredential:

1. Include the Azure.Identity and Microsoft.Extensions.Azure namespaces via using directives.
2. Register the Azure service client using the corresponding Add-prefixed extension method.
3. Pass an instance of DefaultAzureCredential to the UseCredential method.

For example:

using Microsoft.Extensions.Azure;
using Azure.Identity;

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));
    clientBuilder.UseCredential(new DefaultAzureCredential());
});

An alternative to UseCredential is to instantiate DefaultAzureCredential directly:

using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

When the preceding code runs on your local development workstation, it looks in the environment variables for an application service principal or at locally installed developer tools, such as Visual Studio, for a set of developer credentials. Either approach can be used to authenticate the app to Azure resources during local development.

When deployed to Azure, this same code can also authenticate your app to other Azure resources. DefaultAzureCredential can retrieve environment settings and managed identity configurations to authenticate to other services automatically.