Authenticating 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 managed identities - 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 managed identities - 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 application 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.
2 - Assign roles to the managed identity
Next, you need to determine what 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.
3 - Implement DefaultAzureCredential in your application
DefaultAzureCredential
supports multiple authentication methods and determines the authentication method being used at runtime. In this way, your app can use different authentication methods in different environments without implementing environment specific code.
The order and locations in which DefaultAzureCredential
looks for credentials is found at DefaultAzureCredential.
To implement DefaultAzureCredential
, first add the Azure.Identity
and optionally the Microsoft.Extensions.Azure
packages to your application. You can do this using either the command line or the NuGet Package Manager.
Open a terminal environment of your choice in the application project directory and enter the command below.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Azure services are generally accessed using corresponding client classes from the SDK. These classes and your own custom services should be registered in the Program.cs
file so they can be accessed via dependency injection throughout your app. Inside of Program.cs
, follow the steps below to correctly setup your service and DefaultAzureCredential
.
- Include the
Azure.Identity
andMicrosoft.Extensions.Azure
namespaces with ausing
directive. - Register the Azure service using relevant helper methods.
- Pass an instance of the
DefaultAzureCredential
object to theUseCredential
method.
An example of this is shown in the following code segment.
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
Alternatively, you can also utilize DefaultAzureCredential
in your services more directly without the help of additional Azure registration methods, as seen below.
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
When the above code is run on your local workstation during local development, it will look in the environment variables for an application service principal or at Visual Studio, VS Code, the Azure CLI, or Azure PowerShell for a set of developer credentials, either of which 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.
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for