[FEATURE REQ] Support custom Client App ID in DefaultAzureCredential (currently hard-coded to use the az cli client ID)

[ohadschn]

Library or service name.
Azure.Identity

Is your feature request related to a problem? Please describe.
We have strict control over some of our AAD apps, where we allow only specific client IDs to access them.
Specifically, we do not allow the Azure CLI Client ID (04b07795-8ddb-461a-bbee-02f9e1bf7b46).

Unfortunately, when using DefaultAzureCredential, there is no way to specify the client ID to use:

azure-sdk-for-net/sdk/identity/Azure.Identity/src/Constants.cs

Line 17 in cd97a7f

public const string DeveloperSignOnClientId = "04b07795-8ddb-461a-bbee-02f9e1bf7b46";

Adding something like a ClientAppId property to DefaultAzureCredentialOptions would be great (and I imagine not too hard to implement).

[jsquire]

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

[christothes]

Some credentials used by DefaultAzureCredential can be configured with a ClientId via the options. Is there a specific scenario where you've found this not to be possible?

[ghost]

Hi @ohadschn. 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.

[ohadschn]

Some credentials used by DefaultAzureCredential can be configured with a ClientId via the options. Is there a specific scenario where you've found this not to be possible?

It looks likes things have changed since I opened this bug, specifically InteractiveBrowserCredentialClientId and ManagedIdentityClientId which look great. I guess I'd have to exclude all the others though to make sure e.g. token is not taken from cache with the wrong ClientId, which would be a shame if I had the right token in the cache for some reason...

How about something like a unified ClientId instead (or in addition, where the above specific ones can override it), where the same order of credentials is tried (environment, managed identity, etc) and the first one which is successful for that Client ID takes?

[ohadschn]

/unresolve

[christothes]

It looks likes things have changed since I opened this bug, specifically InteractiveBrowserCredentialClientId and ManagedIdentityClientId which look great. I guess I'd have to exclude all the others though to make sure e.g. token is not taken from cache with the wrong ClientId, which would be a shame if I had the right token in the cache for some reason...

Could you talk a bit more about how the current configuration options prevent using the intended ClientId in your specific scenario? For example, in a production scenario, I would think that you'd have a very specific credential to target, such as ManagedIdentity. In a development scenario, you'd have control over which credential would be selected based on your dev environment configuration. My assumption is that it should be rare that the intended credential (and in effect the intended ClientId) in the chain is not chosen.

Another thing to consider is that if you need more control over the credential chain and how it is configured, the ChainedTokenCredential is intended exactly for that. DefaultAzureCredential is definitely the most convenient options, but is not intended for scenarios where total control over the configuration is necessary.

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!