Add authentication via GitHub

[beyang]

This PR updates the CHANGELOG.md file to describe any user-facing changes.

Adds a GitHub authentication provider that enables signing in via GitHub (both GitHub.com and enterprise). Requires creating an OAuth app on the GitHub instance.

Authentication requests repo scope from users. This is to permit us to use the OAuth token to query repository permissions (to be supported in a subsequent PR).

[codecov-io]

Codecov Report

Merging #920 into master will increase coverage by 0.06%.
The diff coverage is 47.42%.

Impacted Files	Coverage Δ
cmd/frontend/internal/auth/providers.go	0% <ø> (ø)	⬆️
...nterprise/cmd/frontend/auth/githuboauth/session.go	0% <0%> (ø)
enterprise/cmd/frontend/auth/githuboauth/user.go	0% <0%> (ø)
enterprise/cmd/frontend/auth/githuboauth/config.go	34.78% <34.78%> (ø)
...terprise/cmd/frontend/auth/githuboauth/provider.go	76.25% <76.25%> (ø)
...rprise/cmd/frontend/auth/githuboauth/middleware.go	80.43% <80.43%> (ø)
enterprise/cmd/frontend/auth/githuboauth/cookie.go	84.21% <84.21%> (ø)
enterprise/cmd/xlang-go/internal/server/deps.go	80.76% <0%> (-0.86%)	⬇️
... and 4 more

[sqs]

Quick comments added. I would also like to try it out locally and test it. Is it ready for me to do that? One of the things I will test is: Does it support linking my existing Sourcegraph account to GitHub? (The auth provider API supports this, but there might be nuances.)

Other things (not necessary if you just want to merge it and try it out behind a feature flag):

• Add docs for this auth provider. Probably the best way is to add the main doc section to the doc/integration/github.md file and link to it from the auth providers doc file (instead of vice versa).
• Give guidance on what to use as the OAuth app name and URL when creating the OAuth client application on GitHub so that users know it is the Sourcegraph app but it is created and owned by their org's site admin--it does not leak the info to Sourcegraph itself.

Questions:

• Why use GitHub OAuth and not GitHub Apps (the new way GitHub prefers you to integrate)?
• Will we be able to reuse a lot of this OAuth code when we want to support GitLab OAuth and other OAuth providers? I think it's better to call this auth provider type: "github" and not type: "oauth" even we end up supporting general OAuth because this is probably going to be an extremely common way of using OAuth.

[sqs]

Full sentences (end with period).

and when you give a github.com URL, always say something to indicate that GHE is also supported, like "accessible from https://github.com/whatever (or the same path on GitHub Enterprise)."

[sqs]

Make the first sentence this to mention GHE:

Configures the GitHub (or GitHub Enterprise) OAuth user authentication provider for SSO.

We and GitHub both call it "sign in" (re: On log-in).

Also, make the last sentence clearer. Something like:

When a user signs into Sourcegraph or links their GitHub account to their existing Sourcegraph account, GitHub will prompt the user for the repo scope.

[beyang]

Quick comments added. I would also like to try it out locally and test it. Is it ready for me to do that? One of the things I will test is: Does it support linking my existing Sourcegraph account to GitHub? (The auth provider API supports this, but there might be nuances.)

Yes, please test locally. It links your existing account the same way the other SSO integrations do so (using verified emails).

• Add docs for this auth provider. Probably the best way is to add the main doc section to the doc/integration/github.md file and link to it from the auth providers doc file (instead of vice versa).
• Give guidance on what to use as the OAuth app name and URL when creating the OAuth client application on GitHub so that users know it is the Sourcegraph app but it is created and owned by their org's site admin--it does not leak the info to Sourcegraph itself.

Will do.

Why use GitHub OAuth and not GitHub Apps (the new way GitHub prefers you to integrate)?

The GitHub app docs state that even after an app is installed, users are still required to go through the OAuth flow to grant user-level permissions and obtain a user-specific token. Such a token is required, because the only way AFAICT that the GitHub API permits querying user repo permissions is through the "show me affiliated repositories for the currently authenticated user" endpoint. It's possible there's a simpler way, but I exhausted my patience after a few hours. OAuth apps suffice for our purposes and I'd like to get through all the auth stuff ASAP so we can focus on building new features.

Will we be able to reuse a lot of this OAuth code when we want to support GitLab OAuth and other OAuth providers? I think it's better to call this auth provider type: "github" and not type: "oauth" even we end up supporting general OAuth because this is probably going to be an extremely common way of using OAuth.

Likely, yes. The library this uses for the OAuth handlers is https://github.com/dghubble/gologin. It currently doesn't have explicit support for GitLab, but I imagine it will be straightforward. I agree that the type should be "github", rather than "oauth". There are enough flavors of OAuth-based authentication out there that I think it would be folly to try to have a single handler for all of them (OpenIDConnect, after all is such a flavor). The auth provider type is already called "github".

[beyang]

Merging this behind a feature flag w/ Quinn's approval. Will update the docs and authz support in a subsequent PR.