mislav
Authentication should go through a user's browser
The current approach to getting an OAuth token is suboptimal. A better approach would be to use xdg-open / open to direct the user to GitHub's site in their browser for authentication and granting authorization. That way, the user can verify that they aren't being fished, use their password manager, clearly see the scopes they are granting authorization for and more.
As it is now, the user must trust that the program is neither malicious nor exploitable.
I wonder how this works for a CLI - it will need to capture the token passed to the browser.
The approach taken in gcloud is to run a local http server and have the OAuth redirect be to localhost. The server listens for the request and stores the token.
Some usability motivation for this change: typing credentials in is tedious, especially if you use a strong password and 2FA. Compare to being brought to your browser, where you are already logged in to GitHub, and clicking a button.
run a local http server and have the OAuth redirect be to localhost. The server listens for the request and stores the token
That should work :+1:. I'm not denying the better user experience aspect.
I'm not denying the better user experience aspect.
Of course! I just added it as motivation since security concerns rarely motivate. :-(
We could make this as part of the auth command initiative: https://github.com/github/hub/issues/225
I like the idea, as it would allow a --webflow flag on the auth command. However, that initiative looks... dead?
Thanks for the suggestion. We'll figure out if we can make it work. From my standpoint, starting a local webserver just for this might be a little tricky and more trouble than it's worth. For people who can't input their username/password on the command-line, we can just ask them to generate a Personal Access Token manually and paste it in.
We definitely want to go forward with the auth command. We just didn't have the time to do it until now.
Why not do it similar to the way Dropbox handles it?
To link this computer to a dropbox account, visit the following url: https://www.dropbox.com/cli_link?host_id=$some_uuid
Then after you authenticate on their website, the next time you try to start the client it picks up the linkage.
@mislav here is the Python utility used in Google's CLI applications: https://github.com/google/oauth2client/blob/master/oauth2client/tools.py
Responding to @mislav's comment on #225 here to keep the discussion together:
For browser-based authentication, hub needs to be registered as an OAuth app. How will we embed securely our own OAuth client tokens in the binary?
This problem applies to any client application so I don't think it's really in scope. See also the Threat: Obtaining Client Secrets section from the spec on the topic.
An OAuth app needs to be registered will a callback URL. I presume you want a callback URL such as http://localhost:
. However, that means that we have to depend on whatever we choose to be available on localhost.
In my last comment on #889, I pointed to the Python utility Google uses in its apps: https://github.com/google/oauth2client/blob/master/oauth2client/tools.py
They attempt to open two ports, and use those as redirection URLs. If they fail, they pass a special URN that signifies that a code should be given back in the browser for the user to paste in.
People need to be able to authenticate to Enterprise instances. An OAuth app that we register with github.com (presumably) won't be known to the Enterprise instance because it won't be in its own database. How do you plan to compensate for that?
I can imagine an entry under hub in git configuration that is set globally for users by whoever operates the instance.
Especially now that github supports u2f, this would be even more valuable, since you can't use u2f to authenticate by typing in a username and password.
GitHub now has an OAuth flow specifically intended for CLI tools: https://docs.github.com/en/developers/apps/authorizing-oauth-apps#device-flow
