Social User forgets they used Social, tries to reset password - What's the Best Practice solution?

Help
1

Challenge - We’ve found this to be a very common use case

  1. New Customer creates a user account with a Social identity (let’s say Google), does their thing and leaves happy
  2. Six months later they return and try to sign in. Forgetting that they used Google, they try a few of their usual email/password combos, none of which will ever work
  3. User drops their email in the Reset Password form, which warmly advises their password reset email has been sent
  4. Password reset email will never be sent, as there’s no user with a “Database” Identity provider and matching email, only a “Google” identity
  5. Frustrated User receives no email, tries a few more times with that and other email addresses, then generates a support ticket or just gives up altogether

Goal

  • Solve for the user’s intention of logging in. Extra points if we can insert the solution immediately after Challenge Step #3 above

Research Performed / Where we’re at

  • This seems like a use case almost everyone encounters eventually if your users are Customers rather than Staff
  • We are already doing some custom Linking Accounts work behind the scenes
  • We’re also already using Rules for doing this automatically on email match
  • We’ve come to the conclusion that the potential solution space here is really broad

Questions

  1. What is the Auth0 team’s idea on best practice?
  2. What have other orgs using Auth0 done for this use case?
1 Like
2

I don’t remember having going through this exact discussion before so I’m afraid that for the second question I’m not really useful, however, I can share some thoughts on this one:

  • assuming you’re using Lock’s built-in password reset the first thing I would do would be to tweak the message to have explicit mention about this possibility; this could be helpful for the subset of users that read stuff.
  • if this continued to be a major problem (after performing the above) I would consider having a custom reset password flow instead of Lock. This reset password flow could go the extra mile and after collecting the email address it would one of the following:
    • if the email address is associated with a database identity continue with the request for password reset through Auth0.
    • if the email address is not associated with a database identity, but is listed as associated with a social connection then my own system would send an email telling the user a password reset was requested, but they don’t actually have a username/password identity and as such…
  • if even the above was still complex for your user base, I would consider allowing email-based passwordless connections and use that to implement an alternative for the usual reset password flow (something for the user that does not really care how he logged in, does not want to login to the same social provider at this time, but just wants to login to your service now). In this flow, you would offer a send me a code/link to my email so I can just login as an alternative to the usual reset password flow; this would indeed need account linking so that passwordless identity would be associated to the same social/database identity having the same verified email address.
3

Awesome suggestions. I suspect #3 is the path we’re going down, with the variation that we’ll probably just generate a database identity matching that email on the fly and link it with their existing social identity, then generate the password reset email as per usual.

Thanks!