GitHub Desktop authentication primarily through browser flow

[billygriffin]

GitHub is deprecating and removing the authorizations API, which handles how most users of GitHub Desktop sign into GitHub from the app. We've always had a secondary method of authenticating via the browser, but we'll need to make this the main authentication method going forward.

Considerations

1. We know protocol handlers can be brittle depending on browser and OS, so we need to ensure people know that the sign in was successful and that they can return to the app. We're imagining this as an interstitial after a successful sign in on github.com.
2. To help discover potential pitfalls with moving to 100% browser authentication, we might start by swapping the prominent default initially so people have something to fall back to before we're forced to remove it altogether.
3. We need to make sure the next version of GitHub Enterprise uses both our protocol handlers (including the auth-specific one) so we get backward compatibility on Enterprise.

[ampinsk]

Designs

Transition state

For the period of time when we're transitioning, we'll need to emphasize the browser log in flow, while still keeping the normal login flow

Welcome screen

This moves all the login options to the first screen, and emphasizes the GitHub.com option.

Preferences

The initial login screen should stay the same:

Then on this screen, I flipped the options and emphasized the GitHub.com option.

Final state

For when the transition is complete, and the only option is to login using your browser

Welcome screen

After the transition is complete, we can remove the login fields

Preferences

After the transition is complete, we can just surface the GitHub.com option directly on this screen.

Interstitial page

The page on dotcom we send you to for the browser login. I left these Help links just as an idea based on other login flows I looked at, so we can change these or remove them entirely if they're not needed.

[rafeca]

I'm going to work on this one, by first implementing the transition state designed by @ampinsk

[billygriffin]

I shared with @niik today that ideally we would keep the alternative method available until it's actually deprecated so we can use the brownout periods to identify any problems and address them.

He shared that ideally we would add support for detecting when dotcom doesn’t support basic auth any more and dynamically enable/disable the username/password flow based on that. That way we’ll adapt during the brownouts and Desktop will automatically adapt to any changes in the deprecation timeline.

This sounds like a great approach to me assuming the implementation isn't too complex.

@ptoomey3 or @tarebyte: We use the verifiable_password_authentication property on the API for GHES to detect whether it supports basic auth. Do you happen to know if we can reliably use that for dotcom as well? Note: this is a public repo so share public things only here. 😄

@niik Please feel free to add or correct anything I missed, and if anyone else has questions please don't hesitate to ask.

[ptoomey3]

TIL verifiable_password_authentication. I think that value would also apply to whether the main web login uses built-in auth or not (I think it is just meant to say that the app verifies passwords vs. deferring to an external source using SAML or something). As such, I'm not sure its value would change after password auth support is removed.

[niik]

I think it is just meant to say that the app verifies passwords vs. deferring to an external source using SAML or something

@ptoomey3 It's possible that the meaning of that property have changed over time but it was originally added specifically for GitHub Desktop (or rather GitHub for Mac/GitHub for Windows) to be able to determine whether we'd have to use the web flow to authenticate.

GHfW/GHfM and GHD have relied on it since 2013 but only for GHES. Our API documentation for the property says

Whether authentication with username and password is supported.

[ptoomey3]

👍 - I think the bit that felt ambiguous to me was the "Whether authentication with username and password is supported." documentation. It isn't clear authentication to what? One might think "to the API" is obvious/implicit, but wasn't 100% sure since that meta endpoint returns other data totally unrelated to the API itself (ex. SSH server key fingerprints).

[niik]

@ptoomey3 Yeah, I think ambiguous is an understatement here and if I hadn't been there for the discussions to add it way back when I wouldn't have been able to make heads or tails of it either.

We've just merged #10020 which makes Desktop respect verifiable_password_authentication for GitHub.com as well as GHES. Is there a tracking issue for the brownouts or another good place where we might add a task so that we remember to flip the property as part of the brownouts?

[benbalter]

Based on #10020 would it be accurate to say that users using basic password auth should upgrade to GitHub Desktop 2.5.4 or later?

[rafeca]

Based on #10020 would it be accurate to say that users using basic password auth should upgrade to GitHub Desktop 2.5.4 or later?

Yes, starting in v2.5.4 GitHub Desktop will disable the user/password authentication once GitHub doesn't support it anymore (note that GitHub Desktop has supported browser-based authentication for quite a long time, but the main way users authenticated was still using user/password).