Managed Identity and DefaultAzureCredential for Azure Authentication

1. The Challenge of Credentials and the DefaultAzureCredential Solution

As a developer, you know the pain of managing secrets: local development connection strings, test environment passwords, production keys. Storing them in appsettings.json is a security risk, and managing them through environment variables can be cumbersome across different deployment stages.

The Azure.Identity library for .NET provides an elegant solution. Its central component is the DefaultAzureCredential class. Instead of telling your code how to authenticate, you simply create an instance of DefaultAzureCredential, and it automatically figures out the best way to authenticate based on the environment where it's running.

This works through a "chain of credentials." DefaultAzureCredential tries a sequence of authentication methods until one succeeds.

This means:

• In Azure (Production): The code will automatically use the App Service's managed identity that we configured.
• On your local machine (Development): The code will use the credentials from your Azure CLI login (az login) or your Visual Studio Azure account.

The result is a single, clean codebase that works everywhere without modification and without containing any secrets.

To solidify this foundational concept, let's review a short article that explains it in detail.

2. Hands-On: Refactoring a .NET App to Use DefaultAzureCredential

Now, let's put theory into practice. We'll refactor a .NET web application to access Azure Blob Storage using its managed identity, completely removing the storage connection string.

The following video provides a clear walkthrough of this exact process.

Your Turn: Let's Write the Code

Follow these steps in a sample .NET 6 (or later) web app project.

Prerequisites:

1. An Azure App Service with a system-assigned managed identity enabled.
2. An Azure Storage Account.
3. Grant the App Service's managed identity the "Storage Blob Data Contributor" role on the Storage Account. You can do this in the Storage Account's Access Control (IAM) blade, similar to how you granted Key Vault permissions in the last lesson.
4. On your local machine, make sure you are logged into the Azure CLI (az login).

Step 1: Update Project Dependencies
In your project's directory, run the following commands to install the necessary NuGet packages:

dotnet add package Azure.Identity
dotnet add package Azure.Storage.Blobs

Step 2: Update appsettings.json
Remove any storage connection strings. Instead, add the URI for your storage account's blob service. You can find this on your Storage Account's Endpoints page in the Azure portal.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "StorageUri": "https://<your-storage-account-name>.blob.core.windows.net/"
}

Step 3: Modify Program.cs for Dependency Injection
We will use dependency injection to provide the BlobServiceClient to our application, which is a standard pattern in modern .NET development.

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

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

// --- START: Add Azure Client ---
// Get the Blob Storage URI from configuration
var storageUri = new Uri(builder.Configuration["StorageUri"]);

// Register the BlobServiceClient for DI.
// It will use DefaultAzureCredential for authentication.
builder.Services.AddSingleton(new BlobServiceClient(storageUri, new DefaultAzureCredential()));
// --- END: Add Azure Client ---

var app = builder.Build();

// ... (rest of Program.cs)

// Example of using the client in a minimal API endpoint
app.MapGet("/blobs", async (BlobServiceClient client) =>
{
    var containers = new List<string>();
    await foreach (var container in client.GetBlobContainersAsync())
    {
        containers.Add(container.Name);
    }
    return containers;
});

app.Run();

Step 4: Test Locally and in Azure

1. Run Locally: Start your application from Visual Studio or with dotnet run. Navigate to the /blobs endpoint. It should successfully connect and list your blob containers, authenticating using your az login credentials.
2. Deploy to Azure: Publish your application to the App Service.
3. Test in Azure: Browse to your deployed application's /blobs endpoint. It will work again, but this time DefaultAzureCredential is using the App Service's managed identity.

You have successfully implemented a secure, credential-free solution that works across environments!

3. Applying the Pattern to Azure Key Vault

The beauty of this pattern is its consistency. Connecting to Key Vault follows the exact same logic. In the previous lesson, we granted your managed identity access to a Key Vault. Now, here's the code to retrieve a secret.

The process is identical: install the client library, get the resource URI, and create the client using DefaultAzureCredential.

To integrate this into your Program.cs, you would first run:
dotnet add package Azure.Security.KeyVault.Secrets

Then, you would register the SecretClient for dependency injection:

// Program.cs
// (Add these lines alongside your BlobServiceClient registration)

// Get Key Vault URI from appsettings.json
var keyVaultUri = new Uri(builder.Configuration["KeyVaultUri"]);

// Register SecretClient for DI
builder.Services.AddSingleton(new SecretClient(keyVaultUri, new DefaultAzureCredential()));

From any controller or minimal API endpoint, you can now inject SecretClient and use it to retrieve secrets, just as we did with BlobServiceClient.

Conclusion

In this lesson, you mastered one of the most important security patterns for Azure development. You connected the infrastructure we've been building directly to your C# application code.

Key Takeaways:

• The Azure.Identity library and its DefaultAzureCredential class are the cornerstones of modern, secure authentication in the Azure .NET SDK.
• DefaultAzureCredential uses a credential chain to automatically authenticate in different environments, enabling a single codebase for both local development and Azure deployments.
• The pattern is consistent across Azure services: instantiate the specific service client (e.g., BlobServiceClient, SecretClient) and pass it a new DefaultAzureCredential() object.
• This approach completely eliminates secrets and connection strings from your application's source code and configuration, dramatically improving your security posture.

Next Steps

Now that you understand the full end-to-end flow—from enabling an identity to granting permissions to using it in code—we'll circle back to focus on managing the Key Vault itself. In the next lesson, we will dive deep into how to create a Key Vault and manage its secrets entirely from the Azure CLI, a critical skill for automating your secure infrastructure.