Matching and merging password-less user accounts

[Jaymassena]

Current design locks an install to the first type of successful authentication: phone number or email. The app must be reinstalled or it's data deleted to clear the lock.

Account Duplicates

If a users logs in with a different phone number or email address than their user account is currently associated with, we will end up with a new account which 90% of the time is not what the user wanted. The match miss could be unintentional because of a typo or on purpose because the user has changed their phone number (same device or new device).

Data loss because of an orphaned user account is very bad so we need a reasonable way to redirect users to their user account when they try to login using a new phone number or email address.

We have one important clue when trying to match on an existing user account. We have the install id for the device/patchr combo which is long lived and user independent. How the install id is generated is different depending on the client platform

iOS: We rely on the IFDA to track the install. This can be reset or limited by the user. It will survive a reinstall/update of Patchr.

Android: We use ANDROID_ID with fallbacks. It will survive a reinstall/update of Patchr. ANDROID_ID changes when the device is factory reset but that is not guaranteed since a number of handset manufacturers have been pretty sloppy about adhering to standards.

When trying to match fails, we could look for any existing user accounts linked to the target install and offer the user a list so they can redirect us to an existing account instead of creating a new one.

If we work off of install id to provide redirect hints to users, they need to be aware of the following:

• To protect personal data, perform a factory reset to wipe the phone before transferring ownership.
• On iOS, if the user resets their IFDA or does a factory reset, we will not provide any hints if they use a phone number or email that does not match their current user record. A new Patchr user will be created.
• On Android, if the user wipes their phone with a factory reset, we will not provide any hints if they use a phone number or email that does not match their current user record. A new Patchr user will be created.

[Jaymassena]

Every time I think about showing a list of user accounts associated with an install and letting the user pick one to essentially take over, it gives me the creeps. I think the reason is that the clients have been designed from day one to support multiple user accounts on the same install (regardless of the likelihood that this will not be the most common case).

That means one of the users (multiple people or one person with multiple accounts/roles) can take control of any other user account just by providing a new phone number or email and choosing the account to morph to. The choice could be intentional or a mistake.

I'm starting to feel like either we have multi account support and the above is a real problem or we only allow an install to be bound to one user account at least when using password-less authentication.

[Jaymassena]

Random idea one: Users still signup using email/phone and password. From that point forward we support password-less login. If the user wants to do something serious like delete their account, merge to an account, etc. we then step up their auth privileges by requiring the password. This effectively becomes like 2FA for scary stuff like taking over a user account via merging. The user has to assert the password which will make it much more difficult to do something potentially serious.

Random idea two: Once a user has created an account, we present the account as a fast login option: UI has photo, text that says "Login as Jay Massena". Tapping triggers password-less flow. Additional option to login as a new user. User enters email/phone and starts the flow. We let the user know that they have logged in as a existing user or will be creating a new user account. If their intent was to login to an existing account but see that they are creating a new account, they can cancel and start over.

[Jaymassena]

I've been looking around for examples of how passwordless is being handled by other applications. Ones prominently featured are slack, medium, and twitter.

Auth0: Service dedicated to apps that want to outsource auth. They have added passwordless to their offerings. In their FAQ they have this: What happens if a user changes email or phone number? A self-service method for changing email or phone number is not included in this version of passwordless authentication. An administrator can change this information using the Auth0 Dashboard.

https://auth0.com/docs/connections/passwordless/faq

Certainly seems very much of a hand-wave to me.

Medium: They only support email for passwordless. It seems their approach is to make sure the user knows that a new account was created so they can retry and get the email right the next time. From their site: Why is it telling me I created a new account instead of logging me into my existing account? Email addresses on Medium are case-sensitive. Be sure you’re entering the email address exactly as you entered it when you created your account. If you can’t remember, contact us at yourfriends@medium.com.

https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd#.zffvyqin4

[georgesnelling]

Here's a line of thought to explore: We offer the option to set a password for your account specifically for the purpose of changing the email or phone number associated with the account.

[georgesnelling]

We've abandoned this idea for now.