Is there any reason that you can't simply allow registrations via other OAuth providers which implicitly registers accounts in the cluster (and links them)? This way an administrator could enable the JIRA provider with a white list on the email address domains allowed, and then everyone can just login with their JIRA account (obviously each new person that registers on the instance would increase the billing amount per month).

• Primarily, their username may collide with a Phacility username, and this seems hard to resolve in a way that makes any sense to users.
• We don't want them to lose access to their Phacility account if they leave the company.
• We don't have any account synchronization code in the upstream, and don't really want to add it since it would only serve Phacility use cases.

In theory, we could:

• Add some kind of concept of "unnamed" accounts in the case of collisions which don't have a username yet, and ask users to pick one the first time they log in.
  • I think this is plausible from a technical and product perspective, but a lot of work/mess and I don't think it's helpful outside of Phacility.
• Deal with losing access in a soft way (e.g., note to the user that they only have one in-cluster oauth source associated with their account and won't be able to log in if they get kicked off that instance). We could just show this prominently when they join or create a second instance, since it isn't relevant until then. This isn't a big deal, it's just bad if someone working at Widget Corp launches a personal instance for a side project and then gets fired suddenly and is locked out of their account.
• But writing the sync stuff is a mess any way you cut it, and the "unnamed" accounts are in the same boat as this.

There are various half-measures we can take here which are less messy, like letting anyone with a verified @domain.com address join an instance, without doing the JIRA and reverse-oauth-sync parts, but it's not clear how much of a use case there is for the various levels of things here.

Oh, and that also wouldn't solve the problem that central auth was aimed at solving, which is:

• If you type phacility.com into your browser (instead of mycompany.phacility.com), you should eventually end up on your instance.

The original driver here was a very complex one (requiring instance-level, non-registration OAuth links to services) but that never went through.

Since, then a much easier use case has come up a couple times, which is basically just enabling Google OAuth to central Phacility. One of the downsides for this:

We could simply enable this, but the account link won't (and can't) synchronize to instances, which feels confusing.

...is true for stuff like Asana/JIRA, but immaterial for Google (and, today, for GitHub, Facebook, Twitter, and so on, since we don't actually use their APIs, although we might in the future).

We should probably resolve T6707 first and I don't want to just turn on every OAuth provider, but I think Google is the most common by far and is quite reasonable to enable (I don't currently anticipate using the API token for anything, so that would moot not having access to it on instances).

This will also create some level of support cost as users mess stuff up, but this is probably modest and mostly resolvable through tooling.

I enabled Google for central auth since I think everything we need for it to work already works fine in the cluster, although it's possible some of the invite flow stuff is a little shaky.

A substantial number of users have linked Google accounts in production and we haven't heard about any issues, so I think that aspect of things is in good shape.