Add support to read mode from environment variables for aad subcommands

[mvanchaa]

Why this change?

Some users are facing intermittent issues with broker mode while invoking build commands which internally invoke AzureAuth.

If they want to switch to a different mode, they need to change the build scripts and use the changed binaries which is not ideal and is difficult for the end user.

Hence, added this support, so that the user can set a mode that's not failing while we investigate the problem with the default mode.

[varshini-elayappen]

@mvanchaa would it be useful to measure how often the default auth mode isn't used? If the number is high, it might help us debug the circumstances in which the default auth mode isn't preferred.

[rewrlution]

I left some comments to this PR.

[Manuha]

@mvanchaa would it be useful to measure how often the default auth mode isn't used? If the number is high, it might help us debug the circumstances in which the default auth mode isn't preferred.

Done.

[mijpeterson]

More of a general comment for us to think about (and not something to take action on for this PR): I think we're starting to enter the territory where I believe AzureAuth is getting more complex than it should be.

This PR, as well as at least one other we've made in the past, are adding changes to address issues that I believe ultimately stem from a problem with our broker auth flow. I think applying these workarounds to unblock customers is an absolutely valid path forward, but I also think we should start to assess why broker/WAM is consistently failing to auth silently for many of our customers.

This doc even calls out that WAM is meant to be an even more effective way of retrieving tokens silently (over IWA which is not supported for Entra-backed "managed accounts"), and yet we're finding that the local MSAL cache and IWA (for service accounts) continue to work better for many of our customers. And the reality is that these flows are starting to be flagged as "non-compliant".

I think it'd be a good idea for us to start looking at fixing our broker flow, and re-standardize our customers' auth flow towards the "compliant" solution.

[rewrlution]

Ship it!

[mvanchaa]

More of a general comment for us to think about (and not something to take action on for this PR): I think we're starting to enter the territory where I believe AzureAuth is getting more complex than it should be.

This PR, as well as at least one other we've made in the past, are adding changes to address issues that I believe ultimately stem from a problem with our broker auth flow. I think applying these workarounds to unblock customers is an absolutely valid path forward, but I also think we should start to assess why broker/WAM is consistently failing to auth silently for many of our customers.

This doc even calls out that WAM is meant to be an even more effective way of retrieving tokens silently (over IWA which is not supported for Entra-backed "managed accounts"), and yet we're finding that the local MSAL cache and IWA (for service accounts) continue to work better for many of our customers. And the reality is that these flows are starting to be flagged as "non-compliant".

I think it'd be a good idea for us to start looking at fixing our broker flow, and re-standardize our customers' auth flow towards the "compliant" solution.

One hundred percent agreed!