Web server auth for generic OAuth remotes

[vdye]

Depends on #41

For hosts like GitHub, GitLab, etc., we want to be able to validate users making requests to the bundle server against the associated host repo permissions. For example, in a bundle server with the routes:

example/public-repo    https://github.com/example/public-repo
example/private-repo   https://github.com/example/private-repo

if a given user has access to public-repo but not private-repo, they should be able to download bundles only for public-repo. However, we don't want the bundle server managing user credentials.

The proposed approach is to have the bundle server use an OAuth Authorization Code Grant workflow to be able to make requests to the remote host on the user's behalf, then have it make a request (e.g. https://api.github.com/repos/<route>) to determine whether the user has access to a given repository (possibly caching the result to avoid hitting request rate limits).

Because bundle server requests are primarily made through Git, the authorization code will need to be sent as a credential through the configured Git credential helper. The default experience (command line username/PW) will be ugly, requiring users to manually construct the authorization server request - including the bundle server client ID - then provide the authorization code as the prompt's "password". More user-friendly credential helpers, like Git Credential Manager, can be pre-configured with the bundle server's OAuth parameters.

A follow-up task to this will be figuring out a way to make this a more user-friendly experience in GCM. That may include implementing a bundle web server endpoint to enable OIDC discovery, then having GCM discover those settings when the bundle server identifies a realm via the WWW-Authenticate header.

Risks/Concerns:

• performance vs. correctness w.r.t caching repo access result
• if we need to request a new access token for every request, is that going to be slow or hit rate limits?
  • maybe instead we just have the filled credential be the access token, not the authorization code

[vtbassmatt]

We validated with one early adopter that this is strongly desired. Paraphrasing, they told us:

Ideally, we would drive all access control from our directory system. We aren't there yet, so the GitHub server is our source of truth for who can access what repositories.

In the future, it will still be fine to get access control information from the GitHub server. The GitHub server will transitively get its access control information from their directory system.