Authenticate Azure Services with Rust

The azure_identity crate is the authentication library that backs every Azure SDK client in Rust, issuing tokens against Microsoft Entra ID (formerly Azure AD). It exposes nine credential types for different environments: DeveloperToolsCredential for local development, ManagedIdentityCredential for Azure VMs, App Service, Functions, and AKS, WorkloadIdentityCredential for Kubernetes workload identity, ClientSecretCredential and ClientCertificateCredential for service principals, AzureCliCredential and AzureDeveloperCliCredential for direct CLI-based auth, AzurePipelinesCredential for Azure Pipelines service connections, and ClientAssertionCredential for custom/federated-identity assertions. DeveloperToolsCredential is the recommended default for local work: it tries developer tools in order, first AzureCliCredential (via az login), then AzureDeveloperCliCredential (via azd auth login).

Use this skill whenever a Rust application needs to authenticate an Azure SDK client (Key Vault, Storage, and other Azure services) against Entra ID, and you need the right credential type for the target environment - a laptop with the Azure CLI installed, an Azure-hosted service that should avoid managing secrets, a Kubernetes cluster with workload identity, or a CI/CD pipeline with a service principal.

For DeveloperToolsCredential and AzureCliCredential/AzureDeveloperCliCredential, the input is simply an existing CLI login session. For ManagedIdentityCredential, the input is either nothing (system-assigned identity) or a ManagedIdentityCredentialOptions { client_id } (user-assigned identity). For ClientSecretCredential, inputs are a tenant ID, client ID, and client secret - or the equivalent AZURE_TENANT_ID/AZURE_CLIENT_ID/AZURE_CLIENT_SECRET environment variables for service-principal auth in production/CI. The output in every case is a credential object that can be passed directly into an Azure SDK client constructor, such as SecretClient::new(vault_url, credential, None).

cargo add azure_identity

Designed to plug straight into any azure_* Rust SDK client (the example shown uses azure_security_keyvault_secrets::SecretClient). Credentials are Arc-wrapped and cheap to clone(), so one credential instance can be reused across multiple SDK clients rather than constructed per-client. An optional tokio feature is available via cargo add azure_identity --features tokio.

Rust developers building services against Azure SDKs who need to pick the correct credential for the deployment target: DeveloperToolsCredential while developing locally, ManagedIdentityCredential in production Azure environments to avoid managing secrets at all, and ClientSecretCredential/ClientCertificateCredential for service-principal-based CI/CD or cross-tenant scenarios. WorkloadIdentityCredential covers the increasingly common case of a Rust service running inside a Kubernetes cluster with federated workload identity configured, letting the pod authenticate to Azure without any long-lived secret ever touching the cluster. AzurePipelinesCredential and ClientAssertionCredential round out the set for teams running CI/CD directly through Azure Pipelines or using federated identity assertions from another identity provider entirely, so nearly every hosting scenario has a credential type purpose-built for it rather than forcing one generic approach everywhere.