The issue is if the builtin email and the oidc email do not match. You could reason someone sets their builtin email to bob@coder, and since we do not verify email addresses, the actual email owner might not be the same person that created the account.

In this case if an admin switches to OIDC and the OIDC email is [email protected], then the user can no longer access their account.

The current feature in experimental resolves this by having the user authenticate with their password, then authenticate with OIDC and we can pair them on the BE. TBD what to do when the emails actually mismatch, but it does guarantee it is the same person.

I see. How do you expect this to work with #7126? I suppose its less of a problem during creation?

In this case if an admin switches to OIDC and the OIDC email is [email protected], then the user can no longer access their account.

I see. At this point, that seems like an irrecoverable state. Any ideas on how we work around it? I'm not sure if we should avoid it entirely so we can support cases where an admin adds OIDC and wants to "enforce" all users to use OIDC now. We have this, but then users are also unable to login

      --disable-password-auth bool, $CODER_DISABLE_PASSWORD_AUTH
          Disable password authentication. This is recommended for security
          purposes in production deployments that rely on an identity provider.
          Any user with the owner role will be able to sign in with their
          password regardless of this setting to avoid potential lock out. If
          you are locked out of your account, you can use the `coder server
          create-admin` command to create a new admin user directly in the
          database.

We also have a LoginTypeNone which disables authentication for the user. So if we need a pending state for the auth, we can use LoginTypeNone.

As for how does an admin create an oidc account, I think we'll have to do something similar to V1, or make them generate some code or token a user can use to signup.

The switching back to built-in is just something that does not make much sense to me. Why would someone want to go from oidc to built-in?

@Emyrk is there a use case to let a recently changed from password to OIDC, to revert back to password?

Seems like the user is forever ODIC after conversion.

CC @shaun

@sharkymark I don't think it is as strong of a use case. OIDC is managed externally, user/pass is managed by the user.

So when you convert to OIDC, you pass authentication to the deployment configuration. If you allow converting back, then the deployment IDP loses control of the user and potentially role/group sync.

So although I see the demo case for converting back and forth, in practice I think only admins should convert a user back to password auth.