[BUG] Creating two instances of DefaultAzureCredential causes requests using the credential to never complete

[amerjusupovic]

Library name and version

Azure.Identity 1.11.0

Describe the bug

Calls to clients that accept TokenCredential as authentication will hang indefinitely, like SecretClient.GetSecretAsync. This only happens when creating multiple instances of DefaultAzureCredential the exact same way, using the same constructor and same parameters but passing each one to separate clients that accept TokenCredential.

Expected behavior

Using multiple identical instances of DefaultAzureCredential will work the same with any client that accepts a TokenCredential parameter for authentication regardless of call order/where the credentials are created.

Actual behavior

Creating multiple identical instances of DefaultAzureCredential and passing them to multiple clients that accept TokenCredential for authentication will result in only the first client being able to resolve requests successfully.

Reproduction Steps

            var cred1 = new DefaultAzureCredential();

            var client1 = new SecretClient(new Uri("https://vaultname.vault.azure.net/"), cred1);
            KeyVaultSecret secret = await client1.GetSecretAsync("message").ConfigureAwait(false);
 
            var cred2 = new DefaultAzureCredential();

            var client2 = new SecretClient(new Uri("https://vaultname.vault.azure.net/"), cred2);
            secret = await client2.GetSecretAsync("message").ConfigureAwait(false);

The last line never completes. However, by changing either one of the credentials to pass in new DefaultAzureCredentialOptions(), the last line will now resolve successfully.

            var cred1 = new DefaultAzureCredential();

            var client1 = new SecretClient(new Uri("https://vaultname.vault.azure.net/"), cred1);
            KeyVaultSecret secret = await client1.GetSecretAsync("message").ConfigureAwait(false);
 
            var cred2 = new DefaultAzureCredential(new DefaultAzureCredentialOptions());

            var client2 = new SecretClient(new Uri("https://vaultname.vault.azure.net/"), cred2);
            secret = await client2.GetSecretAsync("message").ConfigureAwait(false);

This also happens even if different clients are used, like if the first client that's passed a TokenCredential is ConfigurationClient and the second is SecretClient.

Environment

.NET SDK:
Version: 8.0.204
Commit: c338c7548c
Workload version: 8.0.200-manifests.7d36c14f

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.204\

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[christothes]

Hi @amerjusupovic
The second call does return, however it is spending longer attempting to retry the attempts to detect whether the IMDS managed identity endpoint is available. This behavior is a regression from a recent change we made to improve the retry delays of the first attempt to select the credential from the DefaultAzureCredential chain.

We will publish a fix soon. However, even after this is fixed it is a best practice to use a singleton credential instance if there are no differences between how they are configured.

[amerjusupovic]

Thanks for the explanation! I had only tested it with a timeout of 100 seconds so I suppose it would've just taken longer. We'll make sure to recommend using a single credential instance for the app config provider.