Use managed identity before connection strings

Connection strings with embedded secrets are easy to start with and painful to operate. They need rotation, storage, environment-specific handling, incident response, and careful access control across every place they appear.

For Azure-hosted applications, prefer managed identity when the target service supports Microsoft Entra authentication. The app gets an identity from Azure, and permissions are assigned to that identity through roles instead of copied secrets.

This works especially well for services such as Storage, Key Vault, Service Bus, Azure SQL, and many Azure SDK clients. Your code asks for a token through Azure Identity, and Azure decides whether the running workload is allowed to access the resource.

In .NET, the usual starting point is DefaultAzureCredential in composition code:

using Azure.Core;
using Azure.Identity;
using Azure.Storage.Blobs;

TokenCredential credential = new DefaultAzureCredential();

builder.Services.AddSingleton(_ =>
    new BlobServiceClient(
        new Uri(builder.Configuration["Storage:BlobEndpoint"]!),
        credential));

That keeps local development practical. The same code can use developer credentials from the Azure CLI, Visual Studio, or other supported tools on your machine, then use the managed identity when the app runs in Azure.

Choose the identity deliberately. A system-assigned managed identity is tied to one Azure resource and follows its lifecycle. A user-assigned managed identity is a separate Azure resource that can be reused and managed independently, which is often nicer for infrastructure-as-code and stable RBAC assignments.

Azure SQL fits the same identity-first rule, but the shape is different. With Microsoft.Data.SqlClient, you normally configure Microsoft Entra authentication in the connection string, for example Authentication=Active Directory Default, instead of passing a TokenCredential to an Azure SDK client constructor.

Connection strings are still sometimes necessary, but they should not be the default. Start with identity-based access, assign the least role the app needs, and reserve secrets for cases where the dependency cannot support managed identity.