How to authenticate .NET apps to Azure services using the .NET Azure SDK

When an application needs to access an Azure resource such as storage, key vault, or cognitive services, the application must be authenticated to Azure. This is true for all applications, whether deployed to Azure, deployed on-premises, or under development on a local developer workstation. This article describes the recommended approaches to authenticate an app to Azure when using the Azure SDK for .NET.

Recommended app authentication approach

It is recommended that apps use token-based authentication rather than connection strings when authenticating to Azure resources. The Azure SDK for .NET provides classes that support token-based authentication and allow apps to seamlessly authenticate to Azure resources whether the app is in local development, deployed to Azure, or deployed to an on-premises server.

The specific type of token-based authentication an app should use to authenticate to Azure resources depends on where the app is being run and is shown in the following diagram.

• When a developer is running an app during local development - The app can authenticate to Azure using either an application service principal for local development or by using the developer's Azure credentials. Each of these options is discussed in more detail in the section authentication during local development.
• When an app is hosted on Azure - The app should authenticate to Azure resources using a managed identity. This option is discussed in more detail below in the section authentication in server environments.
• When an app is hosted and deployed on-premises - The app should authenticate to Azure resources using an application service principal. This option is discussed in more detail below in the section authentication in server environments.

DefaultAzureCredential

The DefaultAzureCredential class provided by the Azure SDK allows apps to use different authentication methods depending on the environment they're run in. This allows apps to be promoted from local development to test environments to production without code changes. You configure the appropriate authentication method for each environment and DefaultAzureCredential will automatically detect and use that authentication method. The use of DefaultAzureCredential should be preferred over manually coding conditional logic or feature flags to use different authentication methods in different environments.

Details about using the DefaultAzureCredential class are covered later in this article in the section Use DefaultAzureCredential in an application.

Advantages of token-based authentication

Token-based authentication is strongly recommended over using connection strings when building apps for Azure. Token-based authentication offers the following advantages over authenticating with connection strings.

• The token-based authentication methods described below allows you to establish the specific permissions needed by the app on the Azure resource. This follows the principle of least privilege. In contrast, a connection string grants full rights to the Azure resource.
• Whereas anyone or any app with a connection string can connect to an Azure resource, token-based authentication methods scope access to the resource to only the app(s) intended to access the resource.
• In the case of a managed identity, there is no application secret to store. This makes the app more secure because there's no connection string or application secret than can be compromised.
• The Azure.Identity package in the Azure SDK manages tokens for you behind the scenes. This makes using token based authentication as easy to use as a connection string.

Use of connection strings should be limited to initial proof of concept apps or development prototypes that don't access production or sensitive data. Otherwise, the token-based authentication classes available in the Azure SDK should always be preferred when authenticating to Azure resources.

Authentication in server environments

When hosting in a server environment, each application should be assigned a unique application identity per environment the application is run in. In Azure, an app identity is represented by a service principal, a special type of security principal intended to identify and authenticate apps to Azure. The type of service principal to use for your app depends on where your app is running.

Authentication during local development

When an application is run on a developer's workstation during local development, it still must authenticate to any Azure services used by the app. The two main strategies for authenticating apps to Azure during local development are:

Use DefaultAzureCredential in an 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.

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.

1. Include the Azure.Identity and Microsoft.Extensions.Azure namespaces with a using directive.
2. Register the Azure service using relevant helper methods.
3. Pass an instance of the DefaultAzureCredential object to the UseCredential 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.

Exploring the sequence of DefaultAzureCredential authentication methods

Internally, DefaultAzureCredential implements a chain of credential providers for authenticating applications to Azure resources. Each credential provider is able to detect if credentials of that type are configured for the app. DefaultAzureCredential sequentially checks each provider in order and uses the credentials from the first provider that has credentials configured.

The order and locations in which DefaultAzureCredential looks for credentials is found at DefaultAzureCredential.