[FEATURE REQ] ManagedIdentityCredential should fail fast when running outside of Azure

Library name

Azure.Identity

Please describe the feature.

When using DefaultAzureCredential outside of Azure, the ManagedIdentityCredential class retries four times before failing. This adds 8 to 10 seconds to token requests. ManagedIdentityCredential should use a heuristic to determine when the code is not running in Azure (e.g., environment variables, network errors, …), and fail fast.

It is possible to work around this by disabling Managed Identity authentication:

var credential = new DefaultAzureCredential(new DefaultAzureCredentialOptions
{
    ExcludeManagedIdentityCredential = true
});

I do not like this solution as: a) It is hard to discover – many users may just assume that token requests are slow b) It makes code less portable to Azure c) It is boilerplate code that has to be repeated in each application

[heldersousa-planetpayment]

@christothes I ran the code provided by @jonpayne and you can see the results below.

ManagedIdentityCredential is the main culprit when one runs this code from Visual Studio 2022, but VisualStudioCredential can also be really slow when developers are not using Visual Studio 2022 and do dotnet run from the command line (similar times if code is executed from VS Code).

Running from Visual Studio 2022

DefaultAzureCredential.GetToken                     10099.17 ms
EnvironmentCredential.GetToken                          5.40 ms
ManagedIdentityCredential.GetToken                   6128.55 ms
VisualStudioCredential.GetToken                      3880.83 ms

Running from the command line while Visual Studio 2022 was opened)

C:\Users\helder.sousa> dotnet run
DefaultAzureCredential.GetToken                      7921.18 ms
EnvironmentCredential.GetToken                          1.36 ms
ManagedIdentityCredential.GetToken                   6162.71 ms
VisualStudioCredential.GetToken                      1743.74 ms

Running from the command line (Visual Studio 2022 was closed)

C:\Users\helder.sousa> dotnet run
DefaultAzureCredential.GetToken                     16002.06 ms
EnvironmentCredential.GetToken                          1.79 ms
ManagedIdentityCredential.GetToken                   5434.74 ms
VisualStudioCredential.GetToken                      9548.20 ms
VisualStudioCodeCredential.GetToken                     3.20 ms
AzureCliCredential.GetToken                           993.89 ms

Local environment Windows 10 Enterprise (More system specs in this comment https://github.com/Azure/azure-sdk-for-net/issues/24767#issuecomment-1283153172)

<PackageReference Include="Azure.Identity" Version="1.7.0" />

C:\Users\helder.sousa> dotnet --version
6.0.400

[JerryBlake]

@christothes @drdamour,

Hi guys,

I have also hit this issue when using webjobs locally. What drdamour pointed out does seem like an issue, as webjobs extensions does use a DefaultAzureCredentialOptoins when if you don’t set the web job specific configuration in your appsettings.json (or environment vars). This seems like a miss to me as they already are checking with their settings if a customer wants to use a managed identity but fail to remove those from the default check later.

What Chirstothes is saying does work around this issue. If you add the azure client directly with the DI builder (outside of the webjobs builder), web jobs will honor that client instead of creating a new one with the DefaultAzureCredentialsOptions. I think that is the disconnect here in this conversation.