Cbt Nuggets Azure

[Tom Donahou]

TheAzure Identity library provides Microsoft Entra ID (formerly Azure Active Directory) token authentication support across the Azure SDK. It provides a set of TokenCredential implementations which can be used to construct Azure SDK clients which support Microsoft Entra token authentication.

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

Developers using Visual Studio 2017 or later can authenticate a Microsoft Entra account through the IDE. Applications using the DefaultAzureCredential or the VisualStudioCredential can then use this account to authenticate calls in their application when running locally.

To authenticate in Visual Studio, select the Tools > Options menu to launch the Options dialog. Then navigate to the Azure Service Authentication options to sign in with your Microsoft Entra account.

Developers using Visual Studio Code can use the Azure Account extension to authenticate via the editor. Applications using the DefaultAzureCredential or the VisualStudioCodeCredential can then use this account to authenticate calls in their application when running locally.

It's a known issue that VisualStudioCodeCredential 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 via the Azure CLI.

Developers coding outside of an IDE can also use the Azure CLI to authenticate. Applications using the DefaultAzureCredential or the AzureCliCredential can then use this account to authenticate calls in their application when running locally.

For systems without a default web browser, the az login command will use the device code authentication flow. The user can also force the Azure CLI to use the device code flow rather than launching a browser by specifying the --use-device-code argument.

Developers coding outside of an IDE can also use the Azure Developer CLI to authenticate. Applications using the DefaultAzureCredential or the AzureDeveloperCliCredential can then use this account to authenticate calls in their application when running locally.

To authenticate with the Azure Developer CLI, users can run the command azd auth login. For users running on a system with a default web browser, the Azure Developer CLI will launch the browser to authenticate the user.

Developers coding outside of an IDE can also use Azure PowerShell to authenticate. Applications using the DefaultAzureCredential or the AzurePowerShellCredential can then use this account to authenticate calls in their application when running locally.

To authenticate with Azure PowerShell, users can run the command Connect-AzAccount. For users running on a system with a default web browser and version 5.0.0 or later of azure PowerShell, it will launch the browser to authenticate the user.

For systems without a default web browser, the Connect-AzAccount command will use the device code authentication flow. The user can also force Azure PowerShell to use the device code flow rather than launching a browser by specifying the UseDeviceAuthentication argument.

A credential is a class which 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. 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 a variety of 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.

The DefaultAzureCredential is appropriate for most scenarios where the application is intended to ultimately be run in Azure. This is because the DefaultAzureCredential combines credentials commonly used to authenticate when deployed, with credentials used to authenticate in a development environment.

Note: DefaultAzureCredential is intended to simplify getting started with the SDK by handling common scenarios with reasonable default behaviors. Developers who want more control or whose scenario isn't served by the default settings should use other credential types.

As of version 1.10.1, DefaultAzureCredential will attempt 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 will continue to the next credential in the flow. Deployed service credentials will stop the flow with a thrown exception if they're able to attempt token retrieval, but don't receive one. Prior to version 1.10.1, developer credentials would similarly stop the authentication flow if token retrieval failed.

Interactive authentication is disabled in the DefaultAzureCredential by default. This example demonstrates two ways of enabling the interactive authentication portion of the DefaultAzureCredential. When enabled the DefaultAzureCredential will fall back to interactively authenticating the developer via the system's default browser if when no other credentials are available. This example then authenticates an EventHubProducerClient from the Azure.Messaging.EventHubs client library using the DefaultAzureCredential with interactive authentication enabled.

Many Azure hosts allow the assignment of a user-assigned managed identity. The following examples demonstrate configuring DefaultAzureCredential to authenticate a user-assigned managed identity when deployed to an Azure host. The sample code uses the credential to authenticate a BlobClient from the Azure.Storage.Blobs client library. It also demonstrates how you can specify a user-assigned managed identity either by a client ID or a resource ID.

To use a resource ID, set the DefaultAzureCredentialOptions.ManagedIdentityResourceId property. The resource ID takes the form /subscriptions/subscriptionId/resourceGroups/resourceGroupName/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identityName. Because resource IDs can be built by convention, they can be more convenient when there are a large number of user-assigned managed identities in your environment. For example:

While the DefaultAzureCredential is generally the quickest way to get started developing applications for Azure, more advanced users may want to customize the credentials considered when authenticating. The ChainedTokenCredential enables users to combine multiple credential instances to define a customized chain of credentials. This example demonstrates creating a ChainedTokenCredential which will attempt to authenticate using managed identity, and fall back to authenticating via the Azure CLI if managed identity is unavailable in the current environment. The credential is then used to authenticate an EventHubProducerClient from the Azure.Messaging.EventHubs client library.

Credentials default to authenticating to the Microsoft Entra endpoint for the Azure public cloud. To access resources in other clouds, such as Azure Government or a private cloud, configure credentials with the AuthorityHost argument. AzureAuthorityHosts defines authorities for well-known clouds:

As of version 1.10.0, accessing resources protected by Continuous Access Evaluation (CAE) is possible on a per-request basis. This behavior can be enabled by setting the IsCaeEnabled property of TokenRequestContext via its constructor. CAE isn't supported for developer and managed identity credentials.

Errors arising from authentication can be raised on any service client method which makes a request to the service. This is because the first time the token is requested from the credential is on the first call to the service, and any subsequent calls might need to refresh the token. In order to distinguish these failures from failures in the service client Azure Identity classes raise the AuthenticationFailedException with details to the source of the error in the exception message as well as possibly the error message. Depending on the application these errors may or may not be recoverable.

CAUTION: Requests and responses in the Azure Identity library contain sensitive information. Precaution must be taken to protect logs, when customizing the output, to avoid compromising account security.

When troubleshooting authentication issues, you may also want to enable logging of sensitive information. To enable this type of logging, set the IsLoggingContentEnabled property to true. To only log details about the account that was used to attempt authentication and authorization, set IsAccountIdentifierLoggingEnabled to true.

We guarantee that all credential instance methods are thread-safe and independent of each other (guideline).This ensures that the recommendation of reusing credential instances is always safe, even across threads.

Many of the client libraries listed here support authenticating with TokenCredential and the Azure Identity library.There you will also find links where you can learn more about their use, including additional documentation and samples.

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

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.

3a8082e126