Architecture for merging multiple user accounts together

Question

Okay, I got a website where you can register yourself and login. You can also login with your facebook, twitter or linkedin account.

It is important that users only have one account registered. So somehow, I want to merge the accounts of users if they use different methods to login. What is the best solution to solve this?

For instance, the user logs in with his Facebook account. I use the data to register an account for him automatically. Should I sent an e-mail with an username and password of our website? (If this is okay with the policy of Facebook). Should I give them a second screen where they can fill in an username and password? But that's not the idea behind logging in with your Facebook account. It should simplify your procedure to participate.

It's also possible the user has registered himself on our website and the next time he logs in with his twitter account. How can I merge these 2 accounts as one? What's the best way?

So basically my question is: I got 4 different ways a user becomes a member of our website. How can I make sure all these 4 ways only create one account if a user decides to use multiple ways? What's the best flow to make sure that it doesn't become a hassle for the user himself?

---

Edit:

3 years after I asked this question, I am giving the answer myself in a series of articles: https://www.peternijssen.nl/social-network-authentication-setup/
https://www.peternijssen.nl/social-network-authentication-google/
https://www.peternijssen.nl/social-network-authentication-merging-accounts/
https://www.peternijssen.nl/social-network-authentication-twitter-facebook/

Answer 1

I am faced with the exact same task at the moment. The design I worked out is rather simple, but it works well.

The core idea is that models for a local site identity and the third-party site identities are kept isolated, but are later linked. So every user that logs into the site has a local identity which maps to any number of third-party site identities.

A local identity record contains a minimum of information - it could even be a single field - just a primary key. (For my application, I don't care about the user's email, name, or birth date - I just want to know they're the person who has been logging into this account all along.)

The third-party identities contain information relevant only to authenticating with a third-party. For OAuth, this typically means a user identifier (like an id, email, or username) and a service identifier (indicating what site or service was authenticated with). In other parts of the application, outside of the database, that service identifier is paired with a method for retrieving the relevant user identifier from that service, and that is how authentication is performed. For OpenID, we employ the same approach, except the method for authenticating is more generalized (because we can almost always perform the exact same protocol - except we use a different identity URL, and that is our service identifier).

Finally, I keep a records of which third-party identities are paired to what local identity. To generate these records, the flow looks like this:

• A user logs in for the first time using a third-party identity. A local identity record is created, then a third-party identity record, and then they are paired.
• In a control panel, the user is offered the opportunity to link an account by logging in to third-party services. (Pretty straightforward how this works.)
• In the scenario where the user unwittingly makes multiple accounts, the solution is pretty simple. While the user is logged in on one of the accounts, he logs into another which he previously used to log into the site (via the control panel feature above). The web service detects this collision (that the local identity of the logged-in user differs from the local identity that is linked to the third-party identity that just logged in) and the user is prompted with an account merge.

Merging accounts is a matter of merging each individual field of the local identity (which will vary from application to application, and should be easy if you have only a couple fields in your local identity records), and then ensuring the linked third-party identities are linked to the resultant local identity.