Managed Identity for Passwordless Auth

Traditionally, applications connect to Azure services like Storage or Key Vault using connection strings or API keys that are stored in configuration files or environment variables. These credentials can be accidentally committed to source control, exposed in logs, or stolen in a breach. Managed Identity eliminates the need for applications to store credentials entirely — instead, Azure itself issues and rotates a token on behalf of the resource, and the application simply asks Azure for the current token at runtime.

A Managed Identity is an automatically managed service principal in Microsoft Entra ID that is linked to an Azure resource (such as a VM, App Service, or Function App). The Azure platform creates and maintains the identity's credentials — rotating them regularly — so your code never handles a password or secret. Applications running on the resource call the Azure Instance Metadata Service (IMDS) endpoint at http://169.254.169.254 to obtain a short-lived OAuth token, which they then present to Azure services.

There are two types of managed identity: System-assigned is tied to a single Azure resource; it is created when you enable it on the resource and automatically deleted when the resource is deleted. User-assigned is an independent Entra ID identity that you create separately and then attach to one or more Azure resources. User-assigned identities are useful when multiple services (e.g., several Function Apps) need to share the same identity and RBAC permissions, avoiding duplication of role assignments.

After enabling a managed identity, you must grant it RBAC permissions on the target Azure resource. For example, to allow an App Service to read blobs, assign the Storage Blob Data Reader role to the App Service's managed identity on the storage account. RBAC assignments follow the principle of least privilege — grant only the minimum permissions required. Never assign Owner or Contributor to a managed identity unless absolutely necessary.

The Azure SDK provides a DefaultAzureCredential class that automatically tries multiple authentication methods in order: environment variables, workload identity, managed identity, Azure CLI, Visual Studio, and others. When your application runs on Azure (App Service, VM, Function App), DefaultAzureCredential automatically uses the managed identity without any code changes. Locally, developers authenticate via their Azure CLI session. This single credential class works across all environments without conditional logic.

A common pattern is using a managed identity to access Azure Key Vault secrets at runtime. Instead of storing a database password in application settings, you store it in Key Vault and give the app's managed identity the Key Vault Secrets User role on that vault. At startup, the application fetches the secret from Key Vault using DefaultAzureCredential. This pattern ensures secrets are never stored in code, configuration files, or environment variables — they exist only in Key Vault and are fetched ephemerally.

Azure SQL Database supports Entra ID authentication, which means a managed identity can authenticate to SQL without a username/password. To enable this: set an Entra ID admin on the SQL server, then run a CREATE USER statement in the target database for the managed identity's display name, and grant it the appropriate database role. The application connects using the Azure SDK's DefaultAzureCredential and an access token scoped to https://database.windows.net/, entirely passwordless.

In Azure Kubernetes Service, individual pods can obtain managed identity tokens using Workload Identity (the successor to AAD Pod Identity). You create a user-assigned managed identity, federate it with the AKS OIDC issuer, annotate the Kubernetes service account, and the Azure Workload Identity webhook injects the necessary environment variables so the pod's DefaultAzureCredential can obtain a token. This extends passwordless authentication to containerised microservices without storing secrets in Kubernetes Secrets objects.

Even though managed identity credentials are invisible to developers, all token issuance and resource access events are logged. Entra ID Sign-in logs record every token request by a managed identity, including the resource being accessed, the time, and whether the request succeeded. Azure Storage activity logs and Key Vault audit logs record the specific operations performed using the token. These logs are essential for security audits and incident investigations involving managed identities.

If your application currently uses connection strings or API keys, migrate to managed identity in three steps: Step 1 — Enable a managed identity on the compute resource. Step 2 — Assign appropriate RBAC roles to the identity on each target service. Step 3 — Update the application code to use DefaultAzureCredential instead of the connection string. Remove the connection string from App Service configuration and Key Vault once the migration is verified. This migration can typically be completed with minimal code changes in modern Azure SDK applications.

Managed Identity provides four key security benefits over credential-based authentication: No credential storage — nothing to steal or accidentally commit. Automatic rotation — Azure rotates the underlying certificates without downtime. Scoped permissions — identities are granted only the RBAC roles they need, following least privilege. Full audit trail — all access attempts are logged in Entra ID and the accessed service's audit logs. For any new Azure service integration, managed identity should be the default authentication approach.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: managed identity eliminates stored credentials by giving Azure resources an automatically managed Entra ID identity, DefaultAzureCredential in the Azure SDK transparently uses managed identity in Azure and developer credentials locally, and RBAC role assignments on target services control what the identity can access. Next up we explore Azure Service Bus for decoupled messaging between application components.