az login does not work in GitHub Codespaces

[jongio]

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 **

1. Use --use-device-code option
2. 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

[yonzhan]

@jiasli for awareness

[jongio]

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

[noelbundick-msft]

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"

[jongio]

@yonzhan - Did the redirect port change? I was able to do this before with forwardPorts, but the az cli redirect to localhost port changed recently

[jiasli]

Azure CLI 2.30.0 uses MSAL which let the system choose a random available port, instead of fixing to 8400. @rayluo

@jongio, in Azure CLI < 2.30.0, it uses ADAL and a fixed 8400 port.

[jongio]

Can we configure it to be a static port for the codespace scenario?

[jongio]

Maybe a solution is to add --redirectPort to az login so we can call expose that port from codespaces devcontainer and then pass that port to az login

[vhvb1989]

@jongio , the port always changes.
See this workaround: Azure/azure-dev#1006 (comment)

This is also the case on ssh-remote connection. The port-redirect needs to be set just before launching the browser to authenticate, as the url should contains a call back url that is used to return the auth token back to the az cli. That call back url should be different if az is running on codespaces, or using ssh-remote connection to a VM

[sinedied]

@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:

1. that it's running in Codespaces
2. which URL the CLI should redirect to after the login

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

[vhvb1989]

@sinedied

which URL the CLI should redirect to after the login

The Azure Developer CLI (azd) can only use redirect to localhost after login. The login flow would block any other redirect-url as not allowed. Each expected redirect-url must be registered for the login-flow within the app-registration that is used on Azure Identity

[sinedied]

@vhvb1989 Surely that should be doable to update the Azure Identity for AZ CLI to add *githubpreview.dev to the list of allowed redirects.

[vhvb1989]

@sinedied , yes, it is a little more complicated than it should... Adding a new redirect url. Azd has not direct access to add the url, it need to be a chain of requests and approvals :(
The other challenge we would have next, is to supporting setting a redirect url for the MSAL library for go. azd relies on MSAL lib to implement the OAuth2.0 protocol

[iMicknl]

I can reproduce this issue in my local devcontainer (WSL2, Windows 11). Adding the port manually every time does fix this issue.

[jongio]

@jiasli - I'm seeing this again today and don't have a workaround. Can we look into this?

[sinedied]

I made a PR a while back that detects Codespaces and fall back to device code as a workaround: #27443

[jiasli]

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.

@vhvb1989 is correct. AAD blocks arbitrary redirect_uri. For example, if you change the login URL to be something like

https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?...redirect_uri=http%3a%2f%2flocalhost2%3a13833...

AAD will fail with

AADSTS50011: The redirect URI 'http://localhost2:13833' specified in the request does not match the redirect URIs configured for the application '04b07795-8ddb-461a-bbee-02f9e1bf7b46'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

See below excerpt from https://learn.microsoft.com/en-us/entra/identity-platform/reply-url#restrictions-on-wildcards-in-redirect-uris

Restrictions on wildcards in redirect URIs

Wildcard URIs like https://*.contoso.com may seem convenient, but should be avoided due to security implications. According to the OAuth 2.0 specification (section 3.1.2 of RFC 6749), a redirection endpoint URI must be an absolute URI. As such, when a configured wildcard URI matches a redirect URI, query strings and fragments in the redirect URI are stripped.

Wildcard URIs are currently unsupported in app registrations configured to sign in personal Microsoft accounts and work or school accounts. Wildcard URIs are allowed, however, for apps that are configured to sign in only work or school accounts in an organization's Microsoft Entra tenant.

To add redirect URIs with wildcards to app registrations that sign in work or school accounts, use the application manifest editor in App registrations in the Azure portal. Though it's possible to set a redirect URI with a wildcard by using the manifest editor, we strongly recommend you adhere to section 3.1.2 of RFC 6749. and use only absolute URIs.

If your scenario requires more redirect URIs than the maximum limit allowed, consider the following state parameter approach instead of adding a wildcard redirect URI.

Related: MicrosoftDocs/azure-docs#94968

[dorianm]

Hey, same problem here.

We can't use device code (device authorization grant) due to internal policy.

The workaround to change the URL after the redirection (from localhost:xxxx to https://*.githubpreview.dev/) works well, but it's not very convenient for our users. Has someone find a process to simplify this ?

[vhvb1989]

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

[john0isaac]

@vhvb1989, @dorianm there is a simpler workaround that works inside Codespaces just use this command to simulate how azd works.

az login --use-device-code

This is from a tested azd template btw for terraform which requires az login to work with azd
https://github.com/john0isaac/simple-flask-app-terraform

[sinedied]

@john0isaac this is what I proposed in my PR, but it seems some companies disable device code usage so it does not always work 😞 Though it's good enough as a general workaround!

[john0isaac]

I missed that some companies have these internal policies..
I guess that Victor's solution is the only option then.

[syedsajjadaskari]

I use codespaces quite a lot, and I find that log in to Azure needs the --use-device-code flag set.

az login --use-device-code or azd auth login --use-device-code
copy generated code from the terminal and paste it in while login.
and it works perfectly.

[jlian]

@jiasli for this part

According to https://learn.microsoft.com/en-us/entra/identity-platform/reply-url#restrictions-on-wildcards-in-redirect-uris

Wildcard URIs are currently unsupported in app registrations configured to sign in personal Microsoft accounts and work or school accounts.

As Azure CLI falls into this category, it is impossible to register a wildcard redirect URI such as https://*.githubpreview.dev/.

Related: MicrosoftDocs/azure-docs#94968

As I mentioned in MicrosoftDocs/azure-docs#94968 (comment), you actually can put a wildcard in the form of https://*.githubpreview.dev/. You just have to edit the manifest and not use the UI. The documentation issue still stands.

[jongio]

Issue: az login in Codespaces redirects to a random localhost port, causing the redirect to fail.

Analysis and Suggested Changes:

Option 1: Automatically handle port mapping in Azure CLI

• Explanation: This solution would allow Azure CLI to automatically manage port mapping within Codespaces, ensuring a successful redirect without any user intervention.
• Pros: It offers a seamless experience, as the Azure CLI will manage the redirect without requiring the user to specify a port.
• Suggested Improvements:
  • Make sure this feature is thoroughly tested across various Codespaces configurations to ensure it works reliably.
  • Provide clear documentation explaining how the port mapping is managed automatically so users understand the process.
• Reference: PR #28775

Option 2: Force --use-device-code in Codespaces

• Pros: This option ensures that authentication will work within Codespaces by enforcing the device code flow.
• Cons: It might not offer the smoothest experience, as it changes the usual login process.
• Suggested Improvements:
  • Provide clear documentation and possibly a prompt that explains why --use-device-code is being used in Codespaces, helping users understand the reason behind it.
• Reference: PR #27443

---

Issue: Azure CLI AAD application doesn’t allow redirects to GitHub Codespaces.

Suggested Solution:

1. Update the AAD App: Modify the app to support redirects to https://*.githubpreview.dev/. This will require updating the manifest, which will involve working with AAD admins. Jiashuo and others should have the necessary contacts to facilitate this change.

   • Reference: GitHub Issue Comment

2. Update Azure CLI: Ensure that Azure CLI detects when it’s running in a Codespace and automatically redirects to the Codespace URL instead of localhost.

   • Reference: GitHub Issue Comment

[jgbradley1]

It's been 3 years and this is still a problem. If the challenge is that MSAL chooses ports at random, is the simpler solution to first make a fix to that library to enforce a static port selection so that folks can then hardcode configure a codespace with that port?

P.S. for some companies, internal policiess restrict the full use and permissions of using --device-code as a workaround.

[vhvb1989]

If the challenge is that MSAL

I don't think that's the root issue.
I think the root cause here is that az login is not meant for getting one device (your codespace) logged in by using a different device (your local device with access to the CodeSpace).
There's an unresolved debate about if the Codespace device is basically the same device as your local device or not.
In a world where Codespace is a different device, you should not be allowed to log in from that device without enrolling it first to your company (according to default company's access policies).

[jiasli]

We have merged #27443 to force az login to use device code in GitHub Codespaces. It will be included in 2.65.0 (will be released on 2024-10-08).

Maybe a solution is to add --redirectPort to az login so we can call expose that port from codespaces devcontainer and then pass that port to az login

If the challenge is that MSAL chooses ports at random, is the simpler solution to first make a fix to that library to enforce a static port selection so that folks can then hardcode configure a codespace with that port?

Supporting redirect port selection in az login is tracked by #24626.

@vhvb1989 is correct. Auth code flow is meant to be used on the same device (where CLI is run and where the browser is launched). GitHub Codespaces is essentially another device and not localhost. Even if we support redirect port selection in az login, it still won't work as the redirect URI should be https://*.githubpreview.dev/. As I pointed out in #20315 (comment), using a wildcard redirect URI is strongly discouraged.

[vhvb1989]

@jgbradley1 , Have you tried this workaround:

• From your codespace (using web browser), go to the left bottom corner of the window and clic on the name of the codespace. You should see an option to re-open the codespace locally with VSCode (assuming you have VSCode installed in your local device). Click that option.
• Once your codespace is open in VSCode locally, run az login. It will work b/c VSCode handles the auto-redirection from your local-device to the codespace.
• After az login, go back to your codespace in the web browser. az would be already logged in.