[ovidiup]

The account merging part is something your server should handle.

In my app I maintain a users table that has columns (google_account_id, facebook_account_id, twitter_account_id, etc), pointing to individual rows in a separate accounts tables (e.g. google_accounts, facebook_accounts, twitter_accounts etc). When a user adds an existing account_id, I take care of merging the two different users rows, populating appropriately the account_id in one of the rows, then deleting the extraneous users row. I also migrate the existing data referring to the to-be-deleted user row to the one I plan on keeping.

[filearts]

Thanks for the reply. That is the approach I take. Users have one or more identities which seems to be the logical way of handling this regardless of the physical structure used to store the association.

While you gloss over it a bit, the 'migrate the existing data' part is a challenge of its own because it means that suddenly the auth component needs to either know every place where a user<->content association is made or you need some sort of queue set up to publish user merges to all parts of the app in a reliable and durable way so that they can process the migration themselves.

I would say that this is also a UI concern and therefore something that a service like this would need to handle because it should _not happen automatically_. When a user conflict is detected, the user should be able to make a decision via appropriate UI. We would not want two accounts being merged simply because of some degenerate case where someone logged into their account on a borrowed computer.

[jgrowl]

You could create an identities table which consists of a provider and a uid where Users have many identities. Something similar to this:

https://github.com/intridea/omniauth/wiki/Managing-Multiple-...

Use what works for you obviously, but this would have the benefit of scaling easier if you end up ever needing to support additional providers.