Don't fail auth chain if one of the methods work

[simongottschlag]

Hi!

I've been hitting the same "issue" over and over now with the new azidentity package. This should most likely be classified as a feature request and not a bug, since I do think it's by design.

When I develop something using the azidentity and test it locally, I usually test it with one of the methods configured (none of them excluded). Often Azure CLI or Environment - and if both are configured they usually both have the correct permissions / configuration.

The problem I'm hitting is when running in Azure DevOps or GitHub Actions is that they also have MSI - and that MSI usually doesn't have the permissions I need. Then I get this issue:
Received an AuthenticationFailedError, there is an invalid credential in the chain. details: invalid_request Identity not found

It's quite easy to solve, I just make the Exclude option for each of them configurable and disable MSI in the pipelines.

It would be nice if we had a way to actually see that there are other ways available and use them instead.

As an example:

• There is an MSI, but won't be able to authentication
• There is an active Azure CLI session, that is working

If it fails the MSI but Azure CLI works - the chain should be seen as "succesful".

[ArcturusZhang]

Hi @simongottschlag thanks for opening this issue.

@jhendrixMSFT could you please take a look at this?

[catalinaperalta]

Hi @simongottschlag! Thanks for bringing this up! The design of DefaultAzureCredential is meant to give a default set of credentials to work with that will ideally just work in a properly configured environment. However, as I'm sure you've seen, this is actually just an instance of the ChainedTokenCredential with these specific credentials included in the chain. Once the GetToken() method is called it will loop through each credential and attempt to authenticate. If all of the necessary components are available in the environment for one of the credential's to authenticate, then an authentication request will be attempted. If the authentication request fails then the GetToken() request will fail because the information for authentication was not valid or allowed and we will not continue to attempt authentication if authentication has been denied.

For your case in particular, if excluding the MSI credential is not enough I think a ChainedTokenCredential with ClientSecretCredential or ClientCertificateCredential or UsernamePasswordCredential (whichever one you are using from EnvironmentCredential) and AzureCLICredential could work. Alternatively, you could configure your Managed Identity environment with the correct access to authenticate the request you are attempting. Let me know if you need more information about that!

[simongottschlag]

Hi @catalinaperalta !

I fully understand the use case and what's happening, I just think this may cause the end users (those who are using applications built with the package) some confusion. Especially nowdays when GitHub Actions is so wide spread and nearly everyone is using it - without actually understanding that an MSI is used underneath.

If you still don't think anything needs changing, you can close this issue. :)

Thanks!