Design IdP system (currently GitHub-only) so that GitHub is 1 of n possible providers #110
Description
We currently rely on GitHub OAuth for the following reasons:
- At a baseline, as a simple IdP, so we have a notion of "users"
- For its organization capabilities, so users can share DNS verifications across their teams (e.g. not everyone on the team needs access to verify DNS, but one person verifying can unblock the whole team from publishing servers)
- To provide a fallback namespace for publishers who don't want to bother with DNS verification, like
io.github.{username}/* - To handle account management concerns, particularly in an enterprise context, like managing leavers/joiners, 2fa/security reqs, account creation abuse/spam, etc.
Relying on solely GitHub for these functions presents a problem for enterprises that use a competitor (e.g. Gitlab): the only way to conceivably publish a server would be for them to facilitate the publication process through a personal (presumably unauthorized) GitHub account.
A proposed solution: architect the IdP setup so GitHub is just 1 of n possible IdP's. So if you sign in with GitHub, you get access to the io.github.{username/org} namespace + can share DNS verification with your GH org. If you sign in with Gitlab, you get access to community.gitlab.{username/org} + can share DNS with your Gitlab org.
We don't need to plan to implement Gitlab as an IdP out of the gate (unless the Gitlab team or someone with an interest there wants to jump in), but we do need to carve out a path where this is possible. So our database modeling and abstractions in code should make it easy for someone to come in and write a little bit of custom code to make everything work with another IdP (like Gitlab); GitHub should just be the "first reference implementation".