azure-cli: az login does not work in GitHub Codespaces

Describe the bug

az login with default options doesn’t work with GitHub Codespaces. It fails when trying to hit localhost on response.

To Reproduce

Open GitHub Codespaces. run az upgrade to get to 2.30 run az login in GitHub Codespaces, the default codespace is fine.

This is printed:

The default web browser has been opened at https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.

**Workaround **

Use --use-device-code option
Detect if user is in Codespaces by checking CODESPACES=true env var and call az login with --use-device-code

Expected behavior

It should work in GitHub Codespaces with default options.

Environment summary

GitHub Codespaces Linux-5.4.0-1062-azure-x86_64-with-debian-bullseye-sid, Ubuntu 20.04.3 LTS Python 3.6.10 Installer: DEB

azure-cli 2.30.0

Additional context

About this issue

Original URL
State: open
Created 3 years ago
Reactions: 6
Comments: 18 (15 by maintainers)

Commits related to this issue

[Core] az login: Add fallback to device code in Codespaces (#20315) — committed to sinedied/azure-cli by sinedied 9 months ago

Most upvoted comments

@jiasli would you be willing to accept a PR for this?

GitHub CLI solved this, and this could also be solved quite easily in Azure CLI without any additional flags, as Codespaces exposes environment variables that you can use to detect:

that it’s running in Codespaces
which URL the CLI should redirect to after the login

If you’re ok with that I can submit a PR for it.

sinedied on Mar 16, 2023

I hit this regularly and have to use az login --use-device-code to login - which works, but is cumbersome and not a great experience.

The CLI + Codespaces correctly opens a new browser tab and I’m able to authenticate with AAD. After auth, I am redirected to http://localhost:38891/?code=<snip>&client_info=<snip>&state=<snip>&session_state=<snip>, which doesn’t exist when I’m inside a codespace in my browser

If I take that localhost url that fails and run curl <redirect URI> inside my codespace terminal, I’m able to complete a normal login flow

It also works if I replace localhost with my auto-forwarded port for that url. Ex: https://my-repo-5grrrp47jhpg9p-45271.githubpreview.dev/?code=<snip>&client_info=<snip>&state=<snip>&session_state=<snip>

My desired experience is that azure-cli would detect if I’m running it in a codespace terminal session by inspecting the CODESPACES=true environment variable. And then continue to launch the localhost server on a random port, but instead of redirecting from AAD to http://localhost - have the AAD redirect flow send me to my public codespace url, which is a private url/port forward only accessible to me. This value can be found in the CODESPACE_NAME env var. Ex: redirectUri = f"https://{CODESPACE_NAME}-{AZURE_CLI_PORT}.githubpreview.dev"

noelbundick-msft on Apr 1, 2022

Has someone find a process to simplify this ?

@dorianm , the simplest solution/workaround I know is to open the codespace with VSCode - desktop client for doing login. Then you can switch back to browser client. There is an option from bottom left corner, when you are on web-codespaces to re-open the codespace with your desktop client.

This should be fixed in the long term when codespaces add support for managed identity, like an Azure VM

vhvb1989 on Mar 18, 2024

This should be a workaround

Add to devcontainer.json

"forwardPorts": [
		8400
],

But would be nice if CLI defaulted to --use-device-code if in CODESPACES

jongio on Nov 15, 2021