Share via

aio Package

  • Reference

Credentials for asynchronous Azure SDK clients.

Classes

AuthorizationCodeCredential

Authenticates by redeeming an authorization code previously obtained from Microsoft Entra ID.

See Microsoft Entra ID documentation for more information about the authentication flow.
AzureCliCredential

Authenticates by requesting a token from the Azure CLI.

This requires previously logging in to Azure via "az login", and will use the CLI's currently logged in identity.
AzureDeveloperCliCredential

Authenticates by requesting a token from the Azure Developer CLI.

Azure Developer CLI is a command-line interface tool that allows developers to create, manage, and deploy resources in Azure. It's built on top of the Azure CLI and provides additional functionality specific to Azure developers. It allows users to authenticate as a user and/or a service principal against Microsoft Entra ID. The AzureDeveloperCliCredential authenticates in a development environment and acquires a token on behalf of the logged-in user or service principal in Azure Developer CLI. It acts as the Azure Developer CLI logged-in user or service principal and executes an Azure CLI command underneath to authenticate the application against Microsoft Entra ID.

To use this credential, the developer needs to authenticate locally in Azure Developer CLI using one of the commands below:

  • Run "azd auth login" in Azure Developer CLI to authenticate interactively as a user.

  • Run "azd auth login –client-id 'client_id' –client-secret 'client_secret' –tenant-id 'tenant_id'" to authenticate as a service principal.

You may need to repeat this process after a certain time period, depending on the refresh token validity in your organization. Generally, the refresh token validity period is a few weeks to a few months. AzureDeveloperCliCredential will prompt you to sign in again.
AzurePipelinesCredential

Authenticates using Microsoft Entra Workload ID in Azure Pipelines.

This credential enables authentication in Azure Pipelines using workload identity federation for Azure service connections.
AzurePowerShellCredential

Authenticates by requesting a token from Azure PowerShell.

This requires previously logging in to Azure via "Connect-AzAccount", and will use the currently logged in identity.
CertificateCredential

Authenticates as a service principal using a certificate.

The certificate must have an RSA private key, because this credential signs assertions using RS256. See Microsoft Entra ID documentation for more information on configuring certificate authentication.
ChainedTokenCredential

A sequence of credentials that is itself a credential.

Its get_token method calls get_token on each credential in the sequence, in order, returning the first valid token received. For more information, see https://aka.ms/azsdk/python/identity/credential-chains#chainedtokencredential-overview.
ClientAssertionCredential

Authenticates a service principal with a JWT assertion.

This credential is for advanced scenarios. CertificateCredential has a more convenient API for the most common assertion scenario, authenticating a service principal with a certificate.
ClientSecretCredential

Authenticates as a service principal using a client secret.
DefaultAzureCredential

A credential capable of handling most Azure SDK authentication scenarios. See https://aka.ms/azsdk/python/identity/credential-chains#usage-guidance-for-defaultazurecredential.

The identity it uses depends on the environment. When an access token is needed, it requests one using these identities in turn, stopping when one provides a token:

  1. A service principal configured by environment variables. See EnvironmentCredential for more details.

  2. WorkloadIdentityCredential if environment variable configuration is set by the Azure workload identity webhook.

  3. An Azure managed identity. See ManagedIdentityCredential for more details.

  4. On Windows only: a user who has signed in with a Microsoft application, such as Visual Studio. If multiple identities are in the cache, then the value of the environment variable AZURE_USERNAME is used to select which identity to use. See SharedTokenCacheCredential for more details.

  5. The identity currently logged in to the Azure CLI.

  6. The identity currently logged in to Azure PowerShell.

  7. The identity currently logged in to the Azure Developer CLI.

This default behavior is configurable with keyword arguments.
EnvironmentCredential

A credential configured by environment variables.

This credential is capable of authenticating as a service principal using a client secret or a certificate, or as a user with a username and password. Configuration is attempted in this order, using these environment variables:

Service principal with secret:

  • AZURE_TENANT_ID: ID of the service principal's tenant. Also called its 'directory' ID.

  • AZURE_CLIENT_ID: the service principal's client ID

  • AZURE_CLIENT_SECRET: one of the service principal's client secrets

  • AZURE_AUTHORITY_HOST: authority of a Microsoft Entra endpoint, for example "login.microsoftonline.com", the authority for Azure Public Cloud, which is the default when no value is given.

Service principal with certificate:

  • AZURE_TENANT_ID: ID of the service principal's tenant. Also called its 'directory' ID.

  • AZURE_CLIENT_ID: the service principal's client ID

  • AZURE_CLIENT_CERTIFICATE_PATH: path to a PEM or PKCS12 certificate file including the private key.

  • AZURE_CLIENT_CERTIFICATE_PASSWORD: (optional) password of the certificate file, if any.

  • AZURE_AUTHORITY_HOST: authority of a Microsoft Entra endpoint, for example "login.microsoftonline.com", the authority for Azure Public Cloud, which is the default when no value is given.
ManagedIdentityCredential

Authenticates with an Azure managed identity in any hosting environment which supports managed identities.

This credential defaults to using a system-assigned identity. To configure a user-assigned identity, use one of the keyword arguments. See Microsoft Entra ID documentation for more information about configuring managed identity for applications.
OnBehalfOfCredential

Authenticates a service principal via the on-behalf-of flow.

This flow is typically used by middle-tier services that authorize requests to other services with a delegated user identity. Because this is not an interactive authentication flow, an application using it must have admin consent for any delegated permissions before requesting tokens for them. See Microsoft Entra ID documentation for a more detailed description of the on-behalf-of flow.
SharedTokenCacheCredential

Authenticates using tokens in the local cache shared between Microsoft applications.
VisualStudioCodeCredential

Authenticates as the Azure user signed in to Visual Studio Code via the 'Azure Account' extension.

It's a known issue that this credential doesn't work with Azure Account extension versions newer than 0.9.11. A long-term fix to this problem is in progress. In the meantime, consider authenticating with AzureCliCredential.
WorkloadIdentityCredential

Authenticates using Microsoft Entra Workload ID.

Workload identity authentication is a feature in Azure that allows applications running on virtual machines (VMs) to access other Azure resources without the need for a service principal or managed identity. With workload identity authentication, applications authenticate themselves using their own identity, rather than using a shared service principal or managed identity. Under the hood, workload identity authentication uses the concept of Service Account Credentials (SACs), which are automatically created by Azure and stored securely in the VM. By using workload identity authentication, you can avoid the need to manage and rotate service principals or managed identities for each application on each VM. Additionally, because SACs are created automatically and managed by Azure, you don't need to worry about storing and securing sensitive credentials themselves.

The WorkloadIdentityCredential supports Azure workload identity authentication on Azure Kubernetes and acquires a token using the service account credentials available in the Azure Kubernetes environment. Refer to this workload identity overview for more information.

Functions

get_bearer_token_provider

Returns a callable that provides a bearer token.

It can be used for instance to write code like:


   from azure.identity.aio import DefaultAzureCredential, get_bearer_token_provider

   credential = DefaultAzureCredential()
   bearer_token_provider = get_bearer_token_provider(credential, "https://cognitiveservices.azure.com/.default")


   # Usage
   request.headers["Authorization"] = "Bearer " + await bearer_token_provider()

get_bearer_token_provider(credential: AsyncTokenCredential, *scopes: str) -> Callable[[], Coroutine[Any, Any, str]]

Parameters

Name Description
credential
Required
AsyncTokenCredential

The credential used to authenticate the request.
scopes
Required
str

The scopes required for the bearer token.

Returns

Type Description
<xref:coroutine>

A coroutine that returns a bearer token.