Default Azure credential

Konten ini belum tersedia dalam bahasa Anda.

When an Aspire Azure client integration needs to authenticate with an Azure service, it uses a credential. If no credential is explicitly configured, Aspire uses a default credential that is optimized for both local development and production environments in Azure.

Default credential behavior

Starting in Aspire 13.2, the default credential behavior was updated to follow Azure SDK authentication best practices and use deterministic credentials in production environments. Rather than using the parameterless DefaultAzureCredential constructor, Aspire detects the runtime environment and selects the most appropriate credential:

AZURE_TOKEN_CREDENTIALS is set: When the AZURE_TOKEN_CREDENTIALS environment variable is present, a DefaultAzureCredential is created using that environment variable to customize the credential chain. Aspire’s Azure hosting integrations set this variable automatically to ManagedIdentityCredential when deploying to Azure Container Apps or Azure App Service.
Running in Azure (without AZURE_TOKEN_CREDENTIALS): When Aspire detects that the application is running in Azure by the presence of the AZURE_CLIENT_ID environment variable, it uses ManagedIdentityCredential. This ensures deterministic, efficient authentication in production.
Local development: When no Azure environment is detected, a DefaultAzureCredential configured for development is used. This credential excludes EnvironmentCredential, WorkloadIdentityCredential, and ManagedIdentityCredential—leaving only credentials applicable to developer machines, such as the Azure CLI, Visual Studio, or Azure Developer CLI credentials.

Override the default credential

If you need to use a different credential in your application, you can provide your own by configuring the integration’s settings. For example, to use EnvironmentCredential with Azure Blob Storage:

TypeScript
C#

builder.AddAzureBlobServiceClient(
    "blobs",
    settings =>
    {
        settings.Credential = new EnvironmentCredential();
    });

Each Aspire Azure client integration exposes a Credential property in its settings that you can set to any TokenCredential instance.

Reuse the credential in custom code

Integrations and AppHost code outside of Aspire.Hosting.Azure—for example, a pipeline step, lifecycle hook, or custom resource—can resolve the same TokenCredential that Aspire’s Azure hosting integrations use for provisioning and Azure API calls. Resolve ITokenCredentialProvider from dependency injection and read its TokenCredential property:

using Aspire.Hosting.Azure;
using Azure.Core;
using Azure.ResourceManager;
using Microsoft.Extensions.DependencyInjection;

// e.g. inside a pipeline step, lifecycle hook, or custom resource:
var provider = serviceProvider.GetRequiredService<ITokenCredentialProvider>();
TokenCredential credential = provider.TokenCredential;

// Use the credential with any Azure SDK client.
var armClient = new ArmClient(credential);

ITokenCredentialProvider is registered as a singleton by AddAzureProvisioning. Azure resource extension methods invoke AddAzureProvisioning, so using those methods registers the provider indirectly. The credential it exposes is configured by the same Azure provisioning options (tenant ID, credential source, and so on) and matched to the current run or publish execution context, as described in Default credential behavior.

Treat the returned TokenCredential as opaque because its concrete type is an implementation detail that may change between releases; do not rely on casts or type checks.

You can also replace the ITokenCredentialProvider registration with your own implementation if you want to plug in a custom credential for all consumers.