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

[sadasant]

We currently have a DefaultAzureCredential implementation for the browser that does compile but doesn't offer any concrete value, and in most cases won't work (as in, when web-security is enabled on the browsers). We should talk about this with the team (Jonathan mostly) and probably settle on using InteractiveBrowserCredential as the only credential in the chain for the browser.

Also, should InteractiveBrowserCredential be added to DefaultAzureCredential when in node?

[ramya-rao-a]

Another point to consider:

If there are no plans to have any other credential in the chain for the browser, is it even beneficial to advocate for DefaultAzureCredential in browser? How about officially advocating for DefaultAzureCredential in node, and InteractiveBrowserCredential in browser? This would simplify the documentation we have for DefaultAzureCredential where we explain the fallback mechanism

[chradek]

Correct me if I'm wrong, but the user needs to supply at least the tenantId and applicationId to the InteractiveBrowserCredential, right?

If this is the case, then they'd have to pass those to DefaultAzureCredential as well for the browser use-case. Given you don't need to pass those when using DefaultAzureCredential in node.js, there's already a difference in configuration, so I agree that we could just recommend InteractiveBrowserCredential instead.

[sadasant]

@ramya-rao-a @chradek I misread the feedback here!

InteractiveBrowserCredential defaults to "common" tenant and the client ID used for Azure CLI, so there's not a concrete difference in configuration.

This means I should first understand what will happen with the default settings - I believe they're there mainly for the Node version of DefaultAzureCredential.

Also, while DefaultAzureCredential does allow for a tenantId to be specified, a clientId can't be specified through the parameters, so if that default one desn't work by default we should probably:

• Throw if these parameters are not passed through on the browser.
• Drop DefaultAzureCredential.

I'm going to test this and discuss with Scott.

[sadasant]

If the default values do work, we can keep the DefaultAzureCredential for the browser, I think // I'll discuss with Scott.

[ramya-rao-a]

I would recommend not having DefaultAzureCredential use different credentials underneath when in node vs browser. This has the potential of misleading customers that in browser the same fallback mechanism as in node would get used. Though we may document that in case of browser, only InteractiveBrowserCredential gets used (like done in https://github.com/Azure/azure-sdk-for-js/pull/13773), it would be lost in bigger heap of documentation on why DefaultAzureCredential is so great to use and the fallback mechanism it follows.

I'd rather have DefaultAzureCredential throw the same BrowserNotSupportedError in the getToken() method with the error message pointing the user to use InteractiveBrowserCredential instead.

cc @daviwil and @jonathandturner who reviewed the PR

[jonathandturner]

@ramya-rao-a - each of the implementations of DefaultAzureCredential work differently across languages, so there's at least some precedent of "doing what's right in the situation" rather than pulling from a standard set.

It seems relatively harmless to have a chain of one here, and let people build the muscle memory to use DefaultAzureCredential. One of the things we added to the node-based credential over time is developer credentials. That's one possibility in the future is that we could add browser-based developer credentials.

I think the key thing here is "do we think we might nudge people to use DAC in the future?" If so, probably best to keep with the chain of one.

[ramya-rao-a]

Thanks @jonathandturner

That goes back to one of the first questions I posed above

If there are no plans to have any other credential in the chain for the browser, is it even beneficial to advocate for DefaultAzureCredential in browser?

If there are indeed plans in the future of having credential chaining that would apply for the browser, then this would be a good start

[sadasant]

I'm reaching out to the team in general. I'll come up with some answers.

[sadasant]

Here are the answers: https://github.com/Azure/azure-sdk-for-js/pull/13844