Azure Identity client library for Java - version 1.19.0

The Azure Identity library provides Microsoft Entra ID token-based authentication support across the Azure SDK. It provides a set of TokenCredential implementations that can be used to construct Azure SDK clients that support Microsoft Entra token authentication.

Source code | API reference documentation | Microsoft Entra ID documentation

Getting started

Include the package

Include the BOM file

Include the azure-sdk-bom in your project to take a dependency on the stable version of the library. In the following snippet, replace the {bom_version_to_target} placeholder with the version number. To learn more about the BOM, see the Azure SDK BOM README.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.azure</groupId>
            <artifactId>azure-sdk-bom</artifactId>
            <version>{bom_version_to_target}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Then include the direct dependency in the dependencies section without the version tag:

<dependencies>
  <dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-identity</artifactId>
  </dependency>
</dependencies>

Include direct dependency

To take dependency on a particular version of the library that isn't present in the BOM, add the direct dependency to your project as follows:

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-identity</artifactId>
    <version>1.19.0</version>
</dependency>

Prerequisites

Authenticate the client

When debugging and executing code locally, it's typical for a developer to use their own account for authenticating calls to Azure services. There are several developer tools that can be used to perform this authentication in your development environment:

Select each item above to learn about how to configure them for Azure Identity authentication.

Key concepts

Credentials

A credential is a class that contains or can obtain the data needed for a service client to authenticate requests. Service clients across the Azure SDK accept credentials when they're constructed. The service clients use those credentials to authenticate requests to the service.

The Azure Identity library focuses on OAuth authentication with Microsoft Entra ID, and it offers various credential classes capable of acquiring a Microsoft Entra token to authenticate service requests. All of the credential classes in this library are implementations of the TokenCredential abstract class in azure-core, and any of them can be used to construct service clients capable of authenticating with a TokenCredential.

See Credential classes for a complete list of available credential classes.

DefaultAzureCredential

DefaultAzureCredential simplifies authentication while developing apps that deploy to Azure by combining credentials used in Azure hosting environments with credentials used in local development. For more information, see DefaultAzureCredential overview.

Continuation policy

As of v1.10.0, DefaultAzureCredential attempts to authenticate with all developer credentials until one succeeds, regardless of any errors previous developer credentials experienced. For example, a developer credential may attempt to get a token and fail, so DefaultAzureCredential continues to the next credential in the flow. Deployed service credentials stop the flow with a thrown exception if they're able to attempt token retrieval, but don't receive one.

This allows for trying all of the developer credentials on your machine while having predictable deployed behavior.

Examples

You can find more examples of using various credentials in Azure Identity Examples Wiki page.

Authenticate a user in Azure Toolkit for IntelliJ with DefaultAzureCredential

To authenticate using IntelliJ, ensure that configuration instructions here have been successfully completed.

The below example demonstrates authenticating the SecretClient from the azure-security-keyvault-secrets client library using DefaultAzureCredential, on a workstation with IntelliJ IDEA installed, and the user has signed in with an Azure account to the Azure Toolkit for IntelliJ.

See more about how to configure your IntelliJ IDEA in Sign in Azure Toolkit for IntelliJ for IntelliJCredential.

/**
 * DefaultAzureCredential uses the signed-in user from Azure Toolkit for Java.
 */
public void createDefaultAzureCredentialForIntelliJ() {
    DefaultAzureCredential defaultCredential = new DefaultAzureCredentialBuilder()
        .build();

    // Azure SDK client builders accept the credential as a parameter
    SecretClient client = new SecretClientBuilder()
        .vaultUrl("https://{YOUR_VAULT_NAME}.vault.azure.net")
        .credential(defaultCredential)
        .buildClient();
}

Authenticate using Visual Studio Code with DefaultAzureCredential

To authenticate using Visual Studio Code, ensure you have signed in through the Azure Resources extension. The signed-in user is then picked up automatically by DefaultAzureCredential in the Azure SDK for Java.

Prerequisites

Example: Use DefaultAzureCredential with Key Vault

The following example demonstrates authenticating the SecretClient from the azure-security-keyvault-secrets client library using DefaultAzureCredential:

/**
 * DefaultAzureCredential uses the signed-in user from Visual Studio Code
 * via the Azure Resources extension.
 */
public void createDefaultAzureCredentialForVSCode() {
    DefaultAzureCredential defaultCredential = new DefaultAzureCredentialBuilder()
        .build();

    // Azure SDK client builders accept the credential as a parameter
    SecretClient client = new SecretClientBuilder()
        .vaultUrl("https://{YOUR_VAULT_NAME}.vault.azure.net")
        .credential(defaultCredential)
        .buildClient();
}

Authenticate with AKS identity bindings

Azure Kubernetes Service (AKS) identity bindings let multiple clusters share a user-assigned managed identity through a single AKS-managed federated identity credential, avoiding the limit of 20 federated identity credentials per managed identity.

Use WorkloadIdentityCredential directly and call enableAzureProxy() to route authentication through the AKS token proxy. This option is disabled by default and isn't supported by DefaultAzureCredential or ManagedIdentityCredential.

The identity binding API requires azure-identity 1.19.0-beta.2 or a later version containing this feature. It isn't included in 1.18.x packages. If your BOM selects a 1.18.x version, override it with an identity binding-enabled version.

WorkloadIdentityCredential credential = new WorkloadIdentityCredentialBuilder()
    .enableAzureProxy()
    .build();

First configure the AKS identity binding and Kubernetes permissions. The pod must use an authorized service account and have the azure.workload.identity/use: "true" label and azure.workload.identity/use-identity-binding: "true" annotation. For Jobs and Deployments, set these on the pod template. The workload identity webhook provides the configuration:

Environment variable Purpose
AZURE_CLIENT_ID Client ID of the user-assigned managed identity, not its object ID.
AZURE_TENANT_ID Microsoft Entra tenant ID.
AZURE_FEDERATED_TOKEN_FILE Projected Kubernetes service account token file.
AZURE_AUTHORITY_HOST Microsoft Entra authority. Keep this set to the authority, not the proxy URL.
AZURE_KUBERNETES_TOKEN_PROXY HTTPS token proxy endpoint. It must not contain credentials, query parameters, or a fragment.
AZURE_KUBERNETES_SNI_NAME TLS server name used to verify the proxy certificate.
AZURE_KUBERNETES_CA_FILE or AZURE_KUBERNETES_CA_DATA Trusted CA bundle, either a file path or inline PEM text. Don't set both or Base64 encode the inline text.

The credential reloads changes to a CA file on subsequent network requests. A temporarily missing or empty file during rotation retains the previously loaded CA; an invalid nonempty bundle fails authentication. If neither CA setting is provided, the platform trust store is used.

Enabling the option without any proxy settings uses the direct workload identity flow. Partial or invalid proxy configuration fails instead of silently falling back to direct authentication. With proxy configuration present, a dedicated HTTP transport is set on a copy of the credential options. A custom HTTP pipeline retains its usual precedence over HTTP client settings.

An identity binding authorizes token acquisition, not access to Azure resources. Assign Azure roles to the managed identity separately when resource access is required.

Managed Identity support

The Managed identity authentication is supported indirectly via DefaultAzureCredential or directly via ManagedIdentityCredential for the following Azure Services:

Azure Arc supports system-assigned and user-assigned managed identities. ManagedIdentityCredential can select a user-assigned identity by client ID, resource ID, or object ID. DefaultAzureCredential supports client ID and resource ID.

Note: Use azure-identity version 1.7.0 or later to utilize token caching support for managed identity authentication.

Cloud / Sovereign configuration

By default, credentials authenticate to the Microsoft Entra endpoint for Azure Public Cloud. To access resources in other clouds, such as Azure US Government or a private cloud, use one of the following solutions:

  1. Configure credentials with the authorityHost method. For example:
DefaultAzureCredential defaultAzureCredential = new DefaultAzureCredentialBuilder()
    .authorityHost(AzureAuthorityHosts.AZURE_GOVERNMENT)
    .build();

AzureAuthorityHosts defines authorities for well-known clouds.

  1. Set the AZURE_AUTHORITY_HOST environment variable to the appropriate authority host URL. For example, https://login.microsoftonline.us/. Note that this setting affects all credentials in the environment. Use the previous solution to set the authority host on a specific credential.

Not all credentials honor this configuration. Credentials that authenticate through a development tool, such as AzureCliCredential, use that tool's configuration.

Credential classes

Credential chains

Credential Usage Reference
DefaultAzureCredential Provides a simplified authentication experience to quickly start developing apps that run in Azure DefaultAzureCredential overview
ChainedTokenCredential Allows users to define custom authentication flows composing multiple credentials ChainedTokenCredential overview

Authenticate Azure-hosted applications

Credential Usage Example Reference
EnvironmentCredential Authenticates a service principal or user via credential information specified in environment variables
ManagedIdentityCredential Authenticates the managed identity of an Azure resource user-assigned managed identity
system-assigned managed identity
WorkloadIdentityCredential Supports Microsoft Entra Workload ID on Kubernetes example Microsoft Entra Workload ID

Authenticate service principals

Credential Usage Example Reference
AzurePipelinesCredential Authenticates with a service connection in Azure Pipelines. Manage service connections
ClientAssertionCredential Authenticates a service principal using a signed client assertion
ClientCertificateCredential Authenticates a service principal using a certificate example Service principal authentication
ClientSecretCredential Authenticates a service principal using a secret example Service principal authentication

Authenticate users

Credential Usage Example Reference
AuthorizationCodeCredential Authenticates a user with a previously obtained authorization code as part of an OAuth 2.0 auth code flow OAuth 2.0 auth code
DeviceCodeCredential Interactively authenticates a user on devices with limited UI example device code authentication
InteractiveBrowserCredential Interactively authenticates a user with the default system browser example OAuth 2.0 auth code
OnBehalfOfCredential Propagates the delegated user identity and permissions through the request chain On-behalf-of authentication

Authenticate via development tools

Credential Usage Example Reference
AzureCliCredential Authenticates in a development environment with the enabled user or service principal in Azure CLI example Azure CLI authentication
AzureDeveloperCliCredential Authenticates in a development environment with the enabled user or service principal in Azure Developer CLI Azure Developer CLI authentication
AzurePowerShellCredential Authenticates in a development environment with the enabled user or service principal in Azure PowerShell example Azure PowerShell authentication
IntelliJCredential Authenticates in a development environment with the account in Azure Toolkit for IntelliJ example IntelliJ authentication
VisualStudioCodeCredential Authenticates in a development environment with the account in Visual Studio Code

Note: All credential implementations in the Azure Identity library are threadsafe, and a single credential instance can be used to create multiple service clients.

Environment variables

DefaultAzureCredential and EnvironmentCredential can be configured with environment variables. Each type of authentication requires values for specific variables.

Service principal with secret

Variable name Value
AZURE_CLIENT_ID ID of a Microsoft Entra application
AZURE_TENANT_ID ID of the application's Microsoft Entra tenant
AZURE_CLIENT_SECRET one of the application's client secrets

Service principal with certificate

Variable name Value
AZURE_CLIENT_ID ID of a Microsoft Entra application
AZURE_TENANT_ID ID of the application's Microsoft Entra tenant
AZURE_CLIENT_CERTIFICATE_PATH path to a PFX or PEM-encoded certificate file including private key
AZURE_CLIENT_CERTIFICATE_PASSWORD (optional) password for certificate. The certificate can't be password-protected unless this value is specified.

Managed identity (DefaultAzureCredential)

Variable name Value
AZURE_CLIENT_ID The client ID for the user-assigned managed identity.

Configuration is attempted in the preceding order. For example, if values for a client secret and certificate are both present, the client secret is used.

Continuous Access Evaluation

As of v1.10.0, accessing resources protected by Continuous Access Evaluation (CAE) is possible on a per-request basis. This can be enabled using the TokenRequestContext.setCaeEnabled(boolean) API. CAE isn't supported for developer credentials.

Token caching

Token caching is a feature provided by the Azure Identity library that allows apps to:

  • Cache tokens in memory (default) or on disk (opt-in).
  • Improve resilience and performance.
  • Reduce the number of requests made to Microsoft Entra ID to obtain access tokens.

The Azure Identity library offers both in-memory and persistent disk caching. For more information, see the token caching documentation.

Brokered authentication

An authentication broker is an application that runs on a user’s machine and manages the authentication handshakes and token maintenance for connected accounts. Currently, only the Windows Web Account Manager (WAM) is supported. To enable support, use the azure-identity-broker package. For details on authenticating using WAM, see the broker plugin documentation.

Troubleshooting

Credentials raise exceptions when they fail to authenticate or can't execute authentication. When credentials fail to authenticate, the ClientAuthenticationException is raised. The exception has a message attribute, which describes why authentication failed. When ChainedTokenCredential raises this exception, the chained execution of underlying list of credentials is stopped.

When credentials can't execute authentication due to one of the underlying resources required by the credential being unavailable on the machine, the CredentialUnavailableException is raised. The exception has a message attribute that describes why the credential is unavailable for authentication execution. When ChainedTokenCredential raises this exception, the message collects error messages from each credential in the chain.

See the troubleshooting guide for details on how to diagnose various failure scenarios.

Next steps

The Java client libraries listed here support authenticating with TokenCredential and the Azure Identity library. You can learn more about their use, and find additional documentation on use of these client libraries along samples with can be found in the links mentioned here.

The microsoft-graph-sdk also supports authenticating with TokenCredential and the Azure Identity library.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

  • 最終更新: