Can a social IDP user become an email+password user?

Questions
1

We have a certain social identity provider that we would like to phase out for our CIAM users. The most straightforward way I can think of would be to change our end-user facing login screen to take them to a new screen where we explain the situation and prompt users who click on this social IDP to add a password to their account. I’m wondering if this is possible and what API calls need to be made to move the user to the right state?

I found this support article Problem: Password reset does not work with users created via social logins (Google, Facebook, etc.) which makes it clear the basic reset password flow is not suitable.

I’ve looked a little bit at the Identity Provider User Operations API, including the ability to list and unlink an IDP associated with a given user DELETE /api/v1/idps/${idpId}/users/${userId}. Is that the path to follow?

2

Hi @PatrickM. Unlinking the user as you stated would be necessary. Following the unlinking, you may want to trigger a password reset for that user account to ensure the now Okta-sourced account has credentials associated with it. You would also need to ensure that the account link policy does not automatically re-link accounts, should they attempt to sign in with the IdP again after stepping through this process.

1 Like
3

Thank you for your reply Louie. I’m about to roll out a solution for this. What I have found is that we don’t need to unlink the user.

  1. User starts in ACTIVE state with SOCIAL credential provider. This is the state after newly registering with a social provider (user will also be linked to that social provider).

  2. If the User in this state tries to sign in with a password, They get the generic error response “Email and/or password not recognized”

  3. Calling the Okta API for /lifecycle/reset_password will transition the user to PROVISIONED state with OKTA credential provider. If you provide sendEmail=true, this will send the “Password Reset by Admin” email template. We don’t want to send that, so I am calling it with sendEmail=false.

  4. Then we call /lifecycle/reactivate?sendEmail=true, which, since they are PROVISIONED, sends them “User Activation” email template instead.

  5. Either template will include a token that can be exchanged for a state token that will allow setting a new password through /api/v1/authn/credentials/reset_password

Note that the behavior for #3 is different from if the user were not a social user. If you call lifecycle/reset_password for user who has OKTA for their credential provider, they will transition to the RECOVERY state instead, which is what the documentation for this endpoint says will happen.

Aside from being less complicated than looking up the user’s IDPs and DELETEing them, the other benefit of this approach is that it requires fewer permissions. The user and lifecycle endpoints can be called with just the GROUP_ADMIN permission over the user’s group. The /api/v1/idps endpoints and the /api/v1/user/${userId}/idps endpoints all require higher permission - it’s at least ORG_ADMIN, and it might even require SUPER_ADMIN.

4

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.