[BUG] Brokered Credential failure doesn't continue through rest of `ChainedTokenCredential` chain

[afscrome]

Library name and version

Azure.Identity 1.14.0-beta.3 / Azure.Identity.Broker 1.3.0-beta.2

Describe the bug

If you have a ChainedTokenCredential which goes from InteractiveBrowserCredential {UseDefaultBrokerAccount = true} --> DefaultAzureCredential, a failure in the Brokered credential seems to cause the whole chain to terminate, and not proceed onto the next credential in the chain

Expected behavior

If an error occurs getting Brokered credential, I'd expect ChainedTokenCredential to carry on to the next credential in the chain, rather than blowing up completely.

Actual behavior

Unhandled exception. Azure.Identity.AuthenticationFailedException: The ChainedTokenCredential failed due to an unhandled exception: InteractiveBrowserCredential authentication failed:
 ---> Azure.Identity.AuthenticationFailedException: InteractiveBrowserCredential authentication failed:
 ---> MSAL.NetCore.4.69.1.0.MsalServiceException:
        ErrorCode: unknown_broker_error
Microsoft.Identity.Client.MsalServiceException: Unknown Status: Unexpected
Error: 0xffffffff80070520
Context: (pii)
Tag: 0x21420087 (error code -2147023584) (internal error code 557973639)
   at Microsoft.Identity.Client.Internal.Requests.Silent.SilentRequest.<ExecuteAsync>d__5.MoveNext() + 0x620
--- End of stack trace from previous location ---
   at Microsoft.Identity.Client.Internal.Requests.RequestBase.<>c__DisplayClass11_1.<<RunAsync>b__1>d.MoveNext() + 0x5b
--- End of stack trace from previous location ---
   at Microsoft.Identity.Client.Utils.StopwatchService.<MeasureCodeBlockAsync>d__4.MoveNext() + 0x6d
--- End of stack trace from previous location ---
   at Microsoft.Identity.Client.Internal.Requests.RequestBase.<RunAsync>d__11.MoveNext() + 0x366
--- End of stack trace from previous location ---
   at Microsoft.Identity.Client.ApiConfig.Executors.ClientApplicationBaseExecutor.<ExecuteAsync>d__2.MoveNext() + 0x169
--- End of stack trace from previous location ---
   at Azure.Identity.AbstractAcquireTokenParameterBuilderExtensions.<ExecuteAsync>d__0`1.MoveNext() + 0x60
--- End of stack trace from previous location ---
   at Azure.Identity.MsalPublicClient.<AcquireTokenSilentCoreAsync>d__11.MoveNext() + 0x3b1
--- End of stack trace from previous location ---
   at Azure.Identity.MsalPublicClient.<AcquireTokenSilentAsync>d__10.MoveNext() + 0x20d
--- End of stack trace from previous location ---
   at Azure.Identity.InteractiveBrowserCredential.<GetTokenImplAsync>d__56.MoveNext() + 0x5ee
        StatusCode: 0
        ResponseBody:
        Headers:
   --- End of inner exception stack trace ---
   at Azure.Identity.CredentialDiagnosticScope.FailWrapAndThrow(Exception, String, Boolean) + 0x51
   at Azure.Identity.InteractiveBrowserCredential.<GetTokenImplAsync>d__56.MoveNext() + 0x960
--- End of stack trace from previous location ---
   at Azure.Identity.InteractiveBrowserCredential.<GetTokenAsync>d__54.MoveNext() + 0x2aa
--- End of stack trace from previous location ---
   at Azure.Identity.ChainedTokenCredential.<GetTokenImplAsync>d__7.MoveNext() + 0x3e7
   --- End of inner exception stack trace ---
   at Azure.Identity.ChainedTokenCredential.<GetTokenImplAsync>d__7.MoveNext() + 0x6d6
--- End of stack trace from previous location ---
   at Azure.Identity.ChainedTokenCredential.<GetTokenAsync>d__6.MoveNext() + 0x2aa
--- End of stack trace from previous location ---
   at MYAPP.CredentialRetriever.<GetCredentials>d__6.MoveNext() + 0x4de
--- End of stack trace from previous location ---
   at MYAPP.CredentialProvider.<Get>d__7.MoveNext() + 0x60
--- End of stack trace from previous location ---
   at MYAPP.CredentialProvider.<Run>d__6.MoveNext() + 0x5a
--- End of stack trace from previous location ---
   at Program.<<Main>$>d__0.MoveNext() + 0xeb
--- End of stack trace from previous location ---
   at Program.<Main>(String[] args) + 0x28

Reproduction Steps

Use the following credential to get a token by either

1. Run the program in Azure Pipelines.
2. Using runas to run as another user account

new ChainedTokenCredential(
        new InteractiveBrowserCredential(new InteractiveBrowserCredentialBrokerOptions(NativeMethods.GetForegroundWindow())
        {
            UseDefaultBrokerAccount = true,
        }),
        new DefaultAzureCredential(new DefaultAzureCredentialOptions
        {
            ExcludeManagedIdentityCredential = true,
            ExcludeBrokerCredential = true,
        })
    );

I was able to work around this issue by wrapping InteractiveBrowserCredential with the following

class ExceptionHandlingWrappedCredential(TokenCredential inner) : TokenCredential
{
    public override AccessToken GetToken(TokenRequestContext requestContext, CancellationToken cancellationToken)
    {
        try
        {
            return inner.GetToken(requestContext, cancellationToken);
        }
        catch (Exception ex) when  (ex is not CredentialUnavailableException)
        {
            throw new CredentialUnavailableException($"Credential unavailble from {inner.GetType().Name}", ex);
        }
    }

    public override async ValueTask<AccessToken> GetTokenAsync(TokenRequestContext requestContext, CancellationToken cancellationToken)
    {
        try
        {
            return await inner.GetTokenAsync(requestContext, cancellationToken);
        }
        catch (Exception ex) when (ex is not CredentialUnavailableException)
        {
            throw new CredentialUnavailableException($"Credential unavailble from {inner.GetType().Name}", ex);
        }
    }
}

Environment

No response

[github-actions]

Hello @afscrome. I'm an AI assistant for the azure-sdk-for-net repository. I have some suggestions that you can try out while the team gets back to you.

• The behavior you’re seeing is due to the brokered credential (InteractiveBrowserCredential with UseDefaultBrokerAccount) throwing an AuthenticationFailedException rather than a CredentialUnavailableException. This prevents the ChainedTokenCredential from moving on to the next credential.

• As a workaround, wrapping the InteractiveBrowserCredential in a try/catch (and rethrowing as a CredentialUnavailableException for non-recoverable errors) is a viable approach, as you’ve demonstrated in your sample.

• In the long term, we may consider enhancing the brokered credential so that failures that are expected (or due to configuration issues) result in a CredentialUnavailableException, allowing chained credentials to continue.

• For more details on diagnostic behavior and switching between credential types, please refer to the Azure.Identity Broker documentation and the ChainedTokenCredential overview.

The team will get back to you shortly, hopefully this helps in the meantime.

[christothes]

Thanks for reporting this issue @afscrome. We'll look at implementing a fix shortly.