[BUG] OpenTelemetry keeps tracking response code 400 for /metadata/identity/oauth2/token

[bsuchorowskiandea]

Library name and version

Azure.Identity 1.13.2

Describe the bug

Hi,

We are using Azure.Identity in our dotnet core apps runnig in AKS to authenticate to various Azure Services. In general everything works but we are seeing a lot of errors with response_code=400 for /metadata/identity/oauth2/token

We were using DefaultAzureCredentials but we have resigned in favor of using a direct ManagedIdentityCredential (#48270)

We are mixing together two different identities, maybe that's a reason?

• user-assigned ManagedIdentity for authentication to all services except SQL Database ( var credentials = new ManagedIdentityCredential(appConfigMi);
  )
• Workload Idenity for SQL Server (Server=XXXXX.database.windows.net;Database=YYYYYYY;Authentication=Active Directory Workload Identity;Connect Timeout=60)

Expected behavior

no 400 errors in our monitoring

Actual behavior

a lot of 400 calls, even though authentication seems to be working just fine

Reproduction Steps

.

Environment

No response

[github-actions]

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

[christothes]

Hi @bsuchorowskiandea -
The 400 error is expected behavior for the DefaultAzureCredential due to its need to probe for the availability of the IMDS endpoint. This credential is optimized for getting started quickly and easily in a dev/test environment.

You are correct to migrate to the more straightforward ManagedIdentityCredential for production use.

[github-actions]

Hi @bsuchorowskiandea. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[bsuchorowskiandea]

Yeah but it seems that even though we are using only ManagedIdentityCredential, we still see those 400 errors in our monitoring solution. Is there any other scenario where it may be following a similar path? As I wrote above, we are mixing up Managed Identity and Workload Identity in the same app. I wonder if that's might be an actual case, eg. here are our environment variables foir Workload Identity:

In addition to that we are having a user-assigned AKS-level Managed Identity that client_id we store in AppConfigMi and then used for ManagedIdentityCredentials.

EDIT: Actually, we found some more DefaultAzureCredentials in nuget packages used by this applications. Let me get rid of it and go back to you with feedback