Change redirect URI from localhost to 127.0.0.1

[hickford]

The OAuth spec https://datatracker.ietf.org/doc/html/rfc8252#section-8.3 recommends to use 127.0.0.1 instead of localhost:

While redirect URIs using localhost (i.e., "http://localhost:{port}/{path}") function similarly to loopback IP redirects described in Section 7.3, the use of localhost is NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather than localhost avoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user's device.

Examples in code -- BitBucket, GitHub, Azure https://github.com/GitCredentialManager/git-credential-manager/search?q=localhost

[hickford]

NB. This would require changing the redirect URI in the OAuth app settings on GitHub etc. https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps#redirect-urls

Since GitHub allows at most one URI, I can't see how to do this in a backwards compatible way.

[mjcheetham]

NB. This would require changing the redirect URI in the OAuth app settings on GitHub etc. https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps#redirect-urls

You are sadly correct here. I was made aware that we should probably be using the loopback IP address rather than localhost for our redirect URI, but we cannot make that change without breaking older clients 😢

The only other option (in lieu of GitHub adding support for multiple redirect URIs) is to create a new OAuth app with the new redirect URI.. however this just adds more complexity to the management and consent of two separate applications.

[mislav]

For GitHub, instead of redirecting back to either 127.0.0.1 or localhost, GCM should switch to implementing the Device Authorization Flow.

The benefits are that the completed browser flow does not have to redirect to any particular URL (and thus GCM doesn't have to spawn a web server at localhost), and the user is able to complete the browser flow on a different machine (e.g. on their smartphone) than the one where GCM is running as a process.

[hickford]

@mislav GCM already supports OAuth Device Authorization Grant for GitHub, This works great on my headless Rapberry Pi:

Select an authentication method for 'https://github.com/':  
  1. Web browser (default)  
  2. Personal access token  
 option (enter for default):                                                                                                                
 To complete authentication please visit https://github.com/login/device and enter the following code:  
 ABCD-1234

If you can't see the option, you could try forcing it with preference credential.gitHubAuthModes.

[mislav]

@hickford Thanks for the info! I was able to opt into Device flow by doing this:

git config --global credential.gitHubAuthModes device

My next question is, why hasn't GCM auto-detected this when authorizing a git operation from https://github.com, but instead it defaulted to OAuth web app flow? I would argue that the Device flow should be the default and that it's straightforward to feature-detect.

[hickford]

@mislav what version are you using? Update to https://github.com/GitCredentialManager/git-credential-manager/releases/tag/v2.0.567 or later to get #478 "Add explicit GitHub device code authentication option"

My Raspberry Pi has an older version "2.0.498+7ad55fb809" hence 'device code' isn't shown as a separate option.

[mislav]

@hickford I have 2.0.632+478753bbb7 and I do see that my version supports the explicit option of choosing Device flow (as per my previous comment). At the risk of derailing the original topic in this thread, my question is whether I should expect that Device flow is auto-detected as a default authentication method for GitHub.com when nothing is set as credential.gitHubAuthModes (i.e. taking precedence over web app flow). Should I open another thread to ask this in?

[hickford]

@mislav Good idea. With a recent version on a desktop machine I get the following choice:

Select an authentication method for 'https://github.com/':
  1. Web browser (default)
  2. Device code
  3. Personal access token

Whether you see the 'web browser' option depends on the DISPLAY environment variable https://github.com/GitCredentialManager/git-credential-manager/blob/main/src/shared/Core/Interop/Posix/PosixSessionManager.cs

[mislav]

Whether you see the 'web browser' option depends on the DISPLAY environment variable

Ah, I see! DISPLAY isn't set for me on macOS, where I would guess that this variable is never set by default. Nevertheless, I think that maybe GCM could assume that macOS always has desktop capability, since it should be pretty uncommon that developers run macOS in headless mode.

Going back to the original topic: in GitHub CLI, which also used to authorize over OAuth web application flow, we've migrated from http://localhost callback to http://127.0.0.1 in a way that's backwards-compatible, using the same OAuth app. This relied on a feature that's not public. If you'd want help with that, I'm sure we could extend the feature to your OAuth app as well: just email me at mislav@github.com.

However, it's even a better idea to default to device flow whenever possible instead of the web application flow. That's why I was talking so much about device flow in this thread; sure, you could spend time improving the HTTP redirect experience, but a much better long-term solution is to avoid the local server redirect altogether.

[mjcheetham]

My next question is, why hasn't GCM auto-detected this when authorizing a git operation from https://github.com, but instead it defaulted to OAuth web app flow? I would argue that the Device flow should be the default and that it's straightforward to feature-detect.

GCM is detecting this is GitHub.com and should be presenting all possible auth options available (interactive via browser, manually generated PAT, OAuth device code flow).

At the risk of derailing the original topic in this thread, my question is whether I should expect that Device flow is auto-detected as a default authentication method for GitHub.com when nothing is set as credential.gitHubAuthModes (i.e. taking precedence over web app flow). Should I open another thread to ask this in?

When nothing is set for credential.gitHubAuthModes we show a prompt asking the user to pick the flow that suits them.

Whether you see the 'web browser' option depends on the DISPLAY environment variable https://github.com/GitCredentialManager/git-credential-manager/blob/main/src/shared/Core/Interop/Posix/PosixSessionManager.cs
...
Ah, I see! DISPLAY isn't set for me on macOS, where I would guess that this variable is never set by default

We actually use GetProcessWindowStation() and GetUserObjectInformation() on Windows, and SessionGetInfo() on macOS to detect the presence of a GUI environment. On other POSIX operating systems (e.g. Linux), we use the presence of the $DISPLAY variable.

Nevertheless, I think that maybe GCM could assume that macOS always has desktop capability, since it should be pretty uncommon that developers run macOS in headless mode.

That's not always the case 😉(!) Developers should be allowed to SSH in to a macOS machine, imagine SSH-ing in to a headless Mac mini build machine for example (I have done this myself in previous job!). Also think of something like VS Code SSH remote sessions.

Unlike the GitHub CLI, GCM needs to support and present GUI prompts as well as terminal-prompts. IDEs, tools and editors like SourceTree or VS invoke the git executable directly to provider source control. Git can then invoke GCM with no terminal available, and therefore no way for a user to respond to the prompt(!)

[..] (i.e. taking precedence over web app flow). Should I open another thread to ask this in?
...
However, it's even a better idea to default to device flow whenever possible instead of the web application flow.

Yes, this might be better explored in a different issue. Right now we offer all possible options to the user, and the default selection is to use the browser/local-redirect.

[..] in GitHub CLI, which also used to authorize over OAuth web application flow, we've migrated from http://localhost callback to http://127.0.0.1 in a way that's backwards-compatible, using the same OAuth app. This relied on a feature that's not public. If you'd want help with that, I'm sure we could extend the feature to your OAuth app as well: just email me at mislav@github.com.

That's an interesting development! I will reach out.