Feature Request. Option to allow Github Login From Browser
Requestion an option for the github login to offer login from browesr. Github desktop has this feature now. https://github.com/desktop/desktop

It's really great for those who don't know their passwords as they are randomly generated and my password manager then handles it. I have this problem of having to look up every time I open another one of my github repositories in Microsoft/vscode and Git-Credential-Manager-for-Windows github login screen opens up in the background.
The GitHub crew own the feature set for the GitHub authentication dialog. Your suggestion sounds great, but I cannot speak for them.
/CC @shiftkey @Haacked
This requires two things:
- registering GCM as an OAuth app which the user verifies
- registering GCM as a protocol handler on install so that it can handle the browser callback when the OAuth flow completes
There's a significant amount of upkeep alongside contributions to make this experience as magical as it looks.
@whoisj does GCM support Web Oauth login flow for VSTS? Does it do it by registering itself as a protocol handler?
@whoisj does GCM support Web Oauth login flow for VSTS? Does it do it by registering itself as a protocol handler?
I'm sorry, is that English? :innocent:
GCM uses a "kind of" OAuth flow for VSTS, but the "magic" of it is hidden in the Active Directory Authentication Library [ADAL] implementation. You can see that we do have registered OAuth like unique identifiers, but those are generic "client software" identifiers.
Remember that VSTS is the middle man in this equation. The GCM authenticates users with Azure (or if an Active Directory domain is detected, the AD Controller) using ADAL. Then the GCM, using the ADAL access token acquired, requests a PAT from VSTS. The PAT is what is used by Git, and most clients, to access VSTS resources.
Does that help at all? :confounded:
@whoisj a simpler question is when you authenticate with VSTS, do you launch a browser to authenticate. If so, how do you get credentials back to the client?
@shiftkey there might be another way to do this where we have the web flow redirect to a localhost:xxxx address that we're listening to. This is @shana's idea. :smile:
@Haacked we do, and ADAL manages the whole thing - but it does require a IE4 back-channel, or so I'm told. I've not actually inspected the source .
FWIW in the Bitbucket implementation we use OAuth to support 2FA.
When the user makes a request to authorize via OAuth we open an external browser session and spin up a temporary localhost server to catch the callback.