Introduction
When a .NET application needs to access an Azure resource, it must authenticate to Azure. Whether the application is running locally, deployed to an on-premises server, or hosted in Azure, authentication is required to securely connect to Azure services. The Azure Identity library provides a seamless way to authenticate .NET applications using token-based authentication.
Table of Contents
- Recommended App Authentication Approach
- Authentication Methods for Different Environments
- Authentication in Server Environments
- Authentication During Local Development
- Using DefaultAzureCredential in an Application
- Conclusion
Prerequisites
Before implementing authentication using the Azure Identity library, ensure you have the following:
Recommended App Authentication Approach
Using token-based authentication is recommended over connection strings when authenticating to Azure resources. The Azure Identity library enables seamless authentication across different environments without requiring code changes. It supports various authentication mechanisms, including:
- Managed identities (for apps hosted in Azure)
- Application service principals (for on-premises or local development scenarios)
- Developer credentials (for local development using Azure CLI, Visual Studio, or Azure PowerShell)
Why Use Token-Based Authentication?
Token-based authentication provides several benefits over connection strings:
- Principle of Least Privilege: Apps get the minimal necessary permissions.
- Enhanced Security: Avoids exposing sensitive credentials in connection strings.
- Seamless Environment Transition: No need for manual configuration changes when moving from development to production.
- Automatic Token Management: The Azure Identity library handles acquiring and refreshing Microsoft Entra ID tokens.
Authentication Methods for Different Environments
1. Authentication in Server Environments
Depending on where the app is hosted, the authentication method varies:
| Environment |
Authentication Methods |
| Apps Hosted In Azure |
Managed Identity (System-Assigned or User-Assigned) |
| Apps Hosted on-premises |
Application Service Principal |
Managed Identity (Azure Hosted Apps)
A managed identity is a feature of Azure that eliminates the need to manage credentials. An Azure-hosted app can use its managed identity to authenticate to Azure services. We have two ways to enable manage identity.
System-Assigned Managed Identity
A system-assigned managed identity is created and tied directly to an Azure resource (e.g., App Service, Virtual Machine, Function App). The identity lifecycle is managed by Azure, and it is automatically deleted when the resource is deleted.
Example. Authenticating an Azure App Service using System-Assigned Managed Identity
- Enable System Assign Managed Identity on the Azure App Service. To know more, please click here.
- Assign permissions to access required Azure resources (e.g., Key Vault, Storage, etc.).
- Use DefaultAzureCredential in the .NET application to automatically use the managed identity.
public static IHostBuilder ConfigureAppConfigAndKeyVault(this IHostBuilder hostBuilder)
{
hostBuilder.ConfigureAppConfiguration((context, config) =>
{
config.AddAzureAppConfiguration(options =>
{
options.Connect(Environment.GetEnvironmentVariable("AppConfigEndpoint"))
.Select(KeyFilter.Any, LabelFilter.Null)
.ConfigureKeyVault(kv =>
{
kv.SetCredential(new DefaultAzureCredential())
});
});
});
return hostBuilder;
}
In the code example above, we access Azure App Configuration and Key Vault keys without using any Key Vault credentials.
User-Assigned Managed Identity
A user-assigned managed identity is created as an independent Azure resource that can be assigned to multiple services. This is useful when you want multiple resources to share the same identity.
Example. Authenticating an Azure App Service using User-Assigned Managed Identity
- Create a User-Assigned Managed Identity in Azure. To know more, please click here.
- Assign the User-Assigned Managed Identity to an Azure App Service.
- Grant the necessary permissions to the identity on required Azure resources.
- Use DefaultAzureCredential in the .NET application and specify the user-assigned identity.
public static IHostBuilder ConfigureAppConfigAndKeyVault(this IHostBuilder hostBuilder)
{
hostBuilder.ConfigureAppConfiguration((context, config) =>
{
config.AddAzureAppConfiguration(options =>
{
options.Connect(Environment.GetEnvironmentVariable("AppConfigEndpoint"))
.Select(KeyFilter.Any, LabelFilter.Null)
.ConfigureKeyVault(kv =>
{
kv.SetCredential(new DefaultAzureCredential(new DefaultAzureCredentialOptions
{
ManagedIdentityClientId = Environment.GetEnvironmentVariable("ManagedIdentityClientId"),
}));
});
});
});
return hostBuilder;
}
In the code example above, we access Azure App Configuration and Key Vault using a user-assigned managed identity by specifying the ClientId.
Application Service Principal (On-Premises)
For apps running outside Azure, an application service principal must be registered in Microsoft Entra ID. The service principal’s credentials (client ID, tenant ID, and client secret) should be securely stored in environment variables.
- Example: Authenticating an Azure App Configuration
- Register an application in Microsoft Entra ID.
- Assign required permissions to Azure resources.
- Store AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_CLIENT_SECRET in environment variables.
AppSettings settings = new ConfigurationBuilder().AddAzureAppConfiguration(options =>
{
options.Connect("AppConfigurationConnection").
ConfigureKeyVault(kv =>
{
kv.SetCredential(new ClientSecretCredential("TenantId", "KeyVaultClientId", "KeyVaultClientSecrets"));
});
}).AddInMemoryCollection(localSettings).Build().GetSection($"{ConstConfigFile.AppSettings}").Get<AppSettings>();
As shown in the code sample above, we use TenantId, ClientId, and ClientSecret to access Azure App Configuration and Azure Key Vault.
2. Authentication During Local Development
When developing locally, authentication can be done using:
- A dedicated application service principal.
- Developer credentials (e.g., Azure CLI, Visual Studio, VS Code).
Using DefaultAzureCredential enables seamless authentication across different environments without modifying code.
Example. Authenticating Using Developer Credentials
Ensure you’re logged into Azure CLI (az login) or Visual Studio, and then use DefaultAzureCredential in the code as given below:
public static IHostBuilder ConfigureAppConfigAndKeyVault(this IHostBuilder hostBuilder)
{
hostBuilder.ConfigureAppConfiguration((context, config) =>
{
config.AddAzureAppConfiguration(options =>
{
options.Connect(Environment.GetEnvironmentVariable("AppConfigEndpoint"))
.Select(KeyFilter.Any, LabelFilter.Null)
.ConfigureKeyVault(kv =>
{
kv.SetCredential(new DefaultAzureCredential())
});
});
});
return hostBuilder;
}
Set Up Azure Authentication in Visual Studio
- Go to Tools → Options.
- Expand Azure Service Authentication.
- Select Account and choose the authenticated account.
Using DefaultAzureCredential in an Application
DefaultAzureCredential is a chained authentication mechanism that automatically determines the appropriate credential type based on the execution environment. The order in which it checks for credentials is:
- Environment variables (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET)
- Managed identity (if running in Azure)
- Azure CLI, Visual Studio, or VS Code credentials(if running locally)
Conclusion
By leveraging the Azure Identity library and DefaultAzureCredential, you can authenticate .NET applications to Azure services securely and efficiently across all environments. This approach simplifies development, enhances security, and ensures consistency from local workstations to production deployments.
Reference
Thank You, and Stay Tuned for More!
More Articles from my Account