I suppose the biggest difference between us and SaaS apps is the emails in Coder aren't verified when using email/password. There exists a scenario (however unlikely) in the fix you're requesting where an admin creates an account with the wrong email e.g. john@example.com for User A. Later you configure OIDC and encourage users to login using that method. If User A logs in with their real email jon@example.com they'll get a new account. And even worse if you have a different user whose email actually is john@example.com they'll have access to User A's old account.

At the time it was simpler to prevent people using multiple login types but I understand why this is frustrating. I think maybe the solution is to add email verification and allow users with verified emails to login using different forms of SSO.

@bartonip thoughts?

@sreya that's a great point you raise regarding old emails and incorrectly entered emails. That has happened to us once or twice with our SSO with other SaaS apps that do that.

With the old/new email conundrum, how I would expect SSO to work is that its not JUST the email is used to identify the user as OIDC can send other claims like a unique ID for example.

With the account inheritance issue, I have seen this issue solved where when a user logs using OIDC and a standard auth account exists, they are required to log into said account to provide consent to "merge" the accounts.

In my mind, when I look at how SSO works with say, AWS, Office 365, Google Workspace, Sentry, Slack etc. they put the onus on the admin to ensure that the accounts are being linked correctly and I think that most sysadmins would expect this anyway.

In my opinion the best solution would be:

1. Make it so that a unique ID claim is accepted from OIDC
2. Make it so that if someone logs in using OIDC and an existing account with that email already exists, there is the option to merge the accounts after the standard auth password is provided.

I think the above solves my issue with having some devs on standard auth and the rest using OIDC.

Let me know what you think @sreya

I like the steps to merge the accounts @bartonip... if the user provides the password anyways, seems like they could be merged.

@kylecarbs it would be great if this could be added in as we have a couple of users stuck on email/password auth where our new users are all on OIDC which causes a small security issue for us in that we have to specifically remember to deactivate these users accounts when they leave

I'm also interesting in migrating/merging users currently authenticating with passwords to SSO. Let me know if there's something I can do to help, but I might need a few pointers in the codebase.

@kylecarbs would you be able to break down the general steps of how to implement this? I am happy to work on this between food comas over the Christmas/New Year break. @NiklasRosenstein happy if you would like to join?

I think instead of implementing a "merge accounts" feature during login, we could continue to block login for the user until they login with their password and click "link OIDC account" in the settings page or something.

As a part of this, we should also show which account type the user is in the Users table in the UI.

Ok, I got the functionality working for this, just need to polish it all up. I took @deansheather's idea.

On the Account settings page there will be a form to "Link/Merge/Convert (idk wording) with OIDC/Github". There will also be a password field.

How it works is:

1. User submits their password and the OIDC app to connect with ("oidc" or "github").
2. A state string is generated and stored in a new table called oauth_merge_state.
3. The user is then redirected to the normal OIDC auth flow.
4. In the OIDC flow, when we get to the part where the code aborts from the wrong login type, we check if the state string given is a special state string in this new table. If it is, then we assume the user requested this OIDC account as a conversion, and convert the account type.

This state string is paired to a user and OIDC type. So if they generate an OIDC one, they cannot convert to github and vice versa. The state has a 5min expiry. So if the conversion does not happen quickly, the string expires and the flow needs to be restarted.

A pro of this design is that it does not change the OIDC flow much at all. It just adds in the conversion code to a previous error condition.