Code should be part of url on device-login

[paulgmiller]

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

Currently when I do az login

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AWSDQQ7J6 to authenticate.

I have to copy and paste or retype that code into the brower.

Describe the solution you'd like
Many terminals including windows terminal let you just click links. If the code was a query argument I'd click https://microsoft.com/devicelogin?code=AWSDQQ7J6 and save several mouse motions a day. (our policies require relogin once a day minimum per device).

Describe alternatives you've considered
Let az login send a notification to my phone rather than makign me go through the website?

Additional context

[yonzhan]

@jiasli for awareness

[jiasli]

@paulgmiller, this is a really good suggestion and I also feel multiple copy-paste steps tedious and annoying.

Unfortunately, this message

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code HCLRV78QY to authenticate.

is returned by AAD's device code flow and we Azure CLI and the underlying MSAL as a client has no control over it. 😥

[rayluo]

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AWSDQQ7J6 to authenticate.

I have to copy and paste or retype that code into the brower.

"that message is returned by AAD's device code flow... a client has no control over it."

Well, there was a story behind it. 3 years ago during a hackathon, I used to work out a prototype to bypass the manually copy&paste by some other mechanism, and it felt really cool. But that project was shelved indefinitely, because "signing in via Device Code flow without a chance for user to carefully verify the code" is considered as a phishing risk. Since then, AAD's device code flow also patched the weakness and my workaround no longer works.

Nowadays, Azure CLI's underlying authentication library, MSAL, supports a browser-based "interactive auth".

Currently when I do az login

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AWSDQQ7J6 to authenticate.

@paulgmiller, in what scenario you are running the "az login"? Was it run inside a VM that you ssh into?

@jiasli, how does Azure CLI decide whether "az login" would invoke the browser-based interactive auth, or the device code auth? Is it based on browser availability?

@jiasli, @yonzhan, years ago Azure CLI used to support only device code auth, even when running on local desktop. The subsequent introduction of browser-based auth on local desktop was praised as the "improvement of the year". I think we can perhaps bring it to VM, too.

[jiasli]

how does Azure CLI decide whether "az login" would invoke the browser-based interactive auth, or the device code auth? Is it based on browser availability?

The code for deciding whether to use auth code flow is here:

azure-cli/src/azure-cli-core/azure/cli/core/_profile.py

Lines 148 to 150 in d331edf

	if not use_device_code and not can_launch_browser():
	logger.info('No web browser is available. Fall back to device code.')
	use_device_code = True

which calls can_launch_browser:

azure-cli/src/azure-cli-core/azure/cli/core/util.py

Lines 725 to 748 in 0781972

	def can_launch_browser():
	import webbrowser
	platform_name, _ = _get_platform_info()
	if platform_name != 'linux':
	# Only Linux may have no browser
	return True
	# Using webbrowser to launch a browser is the preferred way.
	try:
	webbrowser.get()
	return True
	except webbrowser.Error:
	# Don't worry. We may still try powershell.exe.
	pass
	if is_wsl():
	# Docker container running on WSL 2 also shows WSL, but it can't launch a browser.
	# If powershell.exe is on PATH, it can be called to launch a browser.
	import shutil
	if shutil.which("powershell.exe"):
	return True
	return False

I think we can perhaps bring it (auth code flow) to VM, too.

If the VM has a GUI, it is already supported. If not, we have to do auth in a local web browser and let AAD send the auth code back to VM, other than http://localhost which I believe is not allowed by first party app configuration.

[paulgmiller]

@rayluo two different headless Linux boxes I ssh into. One where I use vscode to do remote development and another a jumpbox where I need to az login to 2-3 different az resources a day.
Both are headless with no gui to speak of but both can port forward

[mrburrito]

Just ran across this issue as we recently switched to using AAD to login to our federated AWS accounts. I'm not sure what "careful verification" I'm supposed to be doing on a randomly generated token. There's plenty of other Microsoft services that allow deeplinked logins. I believe I even found a blog post about how to link various services together using a PowerShell script to generate a QR Code containing the deeplink parameters. It seems like there's no consistency here and what's resulting is a horrible user experience.

If you haven't used AWS' SSO integration with their CLI tool, it's much simpler. If you try to use a command and you're unauthenticated, it auto-opens the browser window, tells you the CLI is attempting to login, and asks you to sign in and authorize the login.

In this case, I would expect the CLI workflow to be similar. If a browser is available, open to the login page with all tokens/ids/etc. already provided and ask me to login and authorize. If the browser isn't available (I also SSH in to a Linux box, so no browser), give me a link that has all the parameters encoded.

Here's the blog where they talk about the kind of deeplink authentication that we're asking for. https://blog.darrenjrobinson.com/azure-ad-and-microsoft-office365-deep-links-and-sign-in-urls/