[Enhancement Proposal] Share login context between Azure CLI and Azure PowerShell

[jiasli]

Is your feature request related to a problem? Please describe.

Sharing login context between Azure CLI and Azure PowerShell is not supported by now.

Describe the solution you'd like

Azure CLI and Azure PowerShell can share their login context so that users can choose to use either command:

	Azure CLI	Azure PowerShell
login	az login	Connect-AzAccount
change context	az account set	Set-AzContext

Additional context

To share login context, Azure CLI and Azure PowerShell must share 2 things:

	Azure CLI	Azure PowerShell
context	azureProfile.json	AzureRmContext.json
token cache	accessTokens.json	TokenCache.dat

For token cache, once both migrate to MSAL, TokenCache.dat and accessTokens.json will be merged into

C:\Users\<username>\AppData\Local\.IdentityService\msal.cache 

so we get shared msal.cache out of the box.

But for AzureRmContext.json and azureProfile.json, it is very hard for Azure CLI to use AzureRmContext.json from Azure PowerShell given the internal implementation logic is such different.

Also, Azure CLI faces another issue for tenant/user isolation which should also be addressed first before sharing login context with Azure PowerShell: #15005.

If this is really something we need to achieve, drastic overhaul of Azure CLI and Azure PowerShell is necessary.

[yonzhan]

A good proposal to share login context across client tools

[cblackuk]

What a great idea! Where do I vote for this? :-)

[jiasli]

Thank you @cblackuk for the comment. You may simply vote on the issue description with a 👍 and our team will evaluate this proposal based on the vote count! 😊

[cblackuk]

Awesome! Thanks :-) Now to everyone else - VOTE people! You will thank us later :-D

[yobyot]

I appreciate that the team is asking for input. And don’t get me wrong: this isn’t a terrible idea. But there are so many other things the cmdlets need more, like expanded, comprehensive, more useable documentation.

This strikes me as the solution to some Microsoft developer’s being inconvenienced rather than a pain the everyday Az module user in an enterprise is facing.

[guidooliveira]

+1 on that! great idea!

[EwertonJordao]

+1 :D.

[rayterrill]

+1 coming from AWS this has been quite confusing

[jiasli]

After dropping Azure Identity and integrating with MSAL, Azure CLI doesn't save token cache to C:\Users\<username>\AppData\Local\.IdentityService\msal.cache. Instead, Azure CLI uses its own msal_token_cache.bin and service_principal_entries.bin as explained in https://github.com/Azure/azure-cli/pull/19853#issuecomment-984440373.

so we get shared msal.cache out of the box.

This is no longer true and sharing token cache now becomes another challenge.

[segraef]

After dropping Azure Identity and integrating with MSAL, Azure CLI doesn't save token cache to C:\Users\<username>\AppData\Local\.IdentityService\msal.cache. Instead, Azure CLI uses its own msal_token_cache.bin and service_principal_entries.bin as explained in #19853 (comment).

so we get shared msal.cache out of the box.

This is no longer true and sharing token cache now becomes another challenge.

@jiasli, coming back to this, do we have any updates or workarounds in this regards?

A fantastic use case is for instance running az cli commands within an already authenticated Azure PowerShell session to enable seamless context sharing.

The only workaround I'm thinking about is using Azure REST leveraging Get-AzAccessToken or going the other way around az login > az account get-access-token > Connect-AzAccount using -AccessToken.