@kylecarbs I stood up OIDC and tested all the edge cases. Things seem to be working as expected. I'm going to update the PR with a summary of the updated behavior.

This PR restricts user to being able to login with only one login type. That means a user that logs in with Github cannot authenticate to the same account with OIDC.

What was your rationale for this decision? Kyle says there are bad security implications with the current implementation. Just confirming that we're aligned.

@ammario I think mainly because the emails aren't verified for built-in. There's also some precedent in other services like Gitlab. For example if I sign in using email/password on Gitlab and then try to sign in with Google using the same email I get an error (for what it's worth I wouldn't say that's the standard, LinkedIn let me swap between both although they required email verification). We also didn't allow this in v1 and heard no complaints about that behavior.

I don't know if there's any realistic security implications but if user A is created with email/password, and then User B signs in with OIDC with a matching email, then user B would be logged into user A's account. Is that realistic? Not really but it's just kinda strange that it could happen.

I don't think there are any security implications at all with signing in between OIDC and Github but I know that with this PR we will process upstream updates to a user's email/username in the OIDC provider and reflect those in the product. If we do that with Github as well then you can get in a situation where a user's email and username is flip flopping between two values every time they sign in with a different provider.

I don't feel particularly strongly one way or the other and I do see how it could be useful for existing users to be able to "migrate" their built-in account to OIDC/Github instead of having to create a new account just to take advantage of new forms of login.

@sreya all SGTM