Azure-sdk-for-js: [Identity] DefaultAzureCredential should use InteractiveBrowserCredential

[sadasant]

While reviewing the Identity package for JS, we realized that DefaultAzureCredential has different behaviors in JS and .Net. In .Net, if no credentials are available, it uses InteractiveBrowserCredential. We should align in JS!

Here's .Net's code: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/identity/Azure.Identity/src/DefaultAzureCredential.cs#L24

Keep in mind that in .Net they use: ExcludeInteractiveBrowserCredential to control whether to use this credential.

Also, if we haven't GAd this, it might make more sense to use DeviceCodeCredential instead of InteractiveBrowserCredential.

[ramya-rao-a]

Have we checked with our friends over at Java and Python SDKs as well?

[sadasant]

@ramya-rao-a Python also uses InteractiveBrowserCredential as the last credential:

https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/identity/azure-identity/azure/identity/_credentials/default.py#L123 they also have the exclude_interactive_browser_credential parameter.

[sadasant]

They have many "exclude" parameters! That's interesting.

[ramya-rao-a]

Also, if we haven't GAd this, it might make more sense to use DeviceCodeCredential instead of InteractiveBrowserCredential.

All users of auto generated JS packages for both data plane and mgmt plane packages so far have been using the Device Code auth as the getting started experience. This can be seen in the code snippet in the generated readme of these files.

But I can see how InteractiveBrowserCredential can be a smoother experience given that I dont have to click on a url and copy paste in the code. This was not an option present in the older auth packages

So, what would be the benefit of choosing DeviceCodeCredential over InteractiveBrowserCredential?

cc @schaabs

[sadasant]

@ramya-rao-a The only advantage of DeviceCodeCredential over InteractiveBrowserCredential is that DeviceCode doesn't need a browser, thus can be used in applications without graphical server or browsers. Let's say somebody deploys a project with Identity in a Heroku instance, they could see the logs and authenticate the remote app manually even though they might have nothing in the environment to authenticate with.

[ramya-rao-a]

This is an area where we should definitely align across languages so that expectation from DefaultAzureCredential is same for a customer when they move from one language to another. Please share an update after discussing with the rest of the Identity feature crew!

[sadasant]

After we talked internally, we decided not to add DeviceCodeCredential to the DefaultAzureCredential pool. We will nonetheless add InteractiveBrowserCredential, and align with the optional parameters.

[sadasant]

Here's the summary of what we talked internally:

• InteractiveBrowserCredential offers a better experience for new users than DeviceCodeCredential.
• People deploying to an environment without a browser would probably not mind to use DeviceCodeCredential directly.
• This means that if we were to add any of these two to DefaultAzureCredential, we would add InteractiveBrowserCredential.
• However, DefaultAzureCredential should never hang waiting for the user's input. So the way we've decided to add it is by adding includeInteractiveCredentials as an option parameter on DefaultAzureCredential to opt-in to InteractiveBrowserCredential.
• There are many differences on the optional parameters of InteractiveBrowserCredential across languages. In particular, several languages have options to drop credentials from the DefaultAzureCredential chain. They have GAd with these credentials, however the Arch board would rather avoid making all languages consistent on those options. Their preference (and I'm favorable to it too) is that if users wanted to pick specific credentials, they would use ChainedTokenCredential directly.

[ramya-rao-a]

https://github.com/Azure/azure-sdk-for-js/pull/14561 adds InteractiveBrowserCredential to DefaultAzureCredential. This is enabled only via enabling an option includeInteractiveCredentials which is disabled by default.

This issue originally came up while reviewing #14356 where we are updating the management plane auto generated packages to support credentials from the @azure/identity package. Before this PR, the code snippet for getting started made use of device code authentication which needed no set up on a user's machine. Moving to DefaultAzureCredential requires users to either login via Azure CLI/VS Code or set up service principal.

https://github.com/Azure/azure-sdk-for-js/pull/14561 helps this matter, but requires us to document the option as well as recommend users not to use this in production. This does not add any value to the alternative of showing the use of DeviceCodeCredential and then recommending the use of DefaultAzureCredential in further development needs and in production.

Since aligning across languages regarding adding InteractiveBrowserCredential to DefaultAzureCredential was also a non-goal, we are not gaining much with this change. So, my recommendation would be to revert the changes in https://github.com/Azure/azure-sdk-for-js/pull/14561 and not rush this in

[sadasant]

@ramya-rao-a thank you!