Account consolidation - ORCID and Google

[chrisgorgo]

I logged in using ORCID and even though my gmail account is my primary contact email on ORCID I was not able to see the datasets I uploaded using my gmail account before. It seems the accounts are not consolidated.

Was this expected @anibalsolon?

[nellh]

This one is an interesting question. Right now if you change your email on ORCID, your OpenNeuro account wouldn't change but the same is not true of a Google account. If you have a non-Gmail Google account and change the email address, this associates your user with a new OpenNeuro account, which is probably not intended either.

Do we want accounts to follow the actual provider account or email address?

[anibalsolon]

@chrisfilo on SciTran, the ORCID user ID is based on the ORCID ID, like 0000-0002-1825-0097, and Google user ID is based on user email. By design, the accounts with different auth provider does not have any relation.

I believe that, in order to enable the same login for google and orcid to the same user, the user schema on SciTran should change a little. There should be a field linking auth providers to the user, and the auth process should not be based on _id field but on accounts, such as:

{
	_id: "[email protected]",

	accounts: [
		{
			kind: "google",
			email: "[email protected]"
		},
		{
			kind: "orcid",
			orcid: "0000-0002-1825-0097"
		}
	]
}

And there should be an option on user settings to connect a ORCiD on its account and maybe an option to merge SciTran accounts.

[chrisgorgo]

This seems more complex than I thought (especially considering that people can switch email addresses in orcid). Focusing on #171 and #186 makes more sense for now (in context of China accessibility).

[nellh]

The new authentication system is not far from supporting this due to a refactor to remove any provider specific details from the React side of things. We could revisit this soon, remaining tasks are:

• [x] Assign a generic ID to each user.
• [ ] Provide an API and UI users to merge accounts.

[nellh]

Users now have the generic account id assigned to them. These are still 1:1 with provider accounts but this way resources associated with the user don't need to be updated if their provider id changes for some reason.

Implementation is required to merge existing duplicates. For a user with a Google and ORCID account on the site who wanted to merge these two accounts a series of steps is required.

1. They must login to the primary OpenNeuro account and add the secondary OpenNeuro account.
2. They must authenticate with the secondary external provider account to establish ownership.
3. The OpenNeuro user record must be updated to reference the secondary external provider account.
4. The resources tied to the secondary OpenNeuro account need to be associated with the primary OpenNeuro account.
5. The secondary OpenNeuro account should be deleted.

One open question is how we avoid creating more duplicate accounts in the future (particularly if more auth providers are supported)? This results in some significant maintenance burden to make sure the merge process continues to work as new records are associated with user accounts.

[chrisgorgo]

I would expect this to be a common issue - isn't there a solution in http://www.passportjs.org/ ?

[anibalsolon]

I do not think that passportjs would solve the duplication issue, since they do not store a state/linking between the strategies.

One strategy that I've seen (and looks counterintuitive), is:

1. Login with Google

2. If google token is new, require a username/pass (weird, right?)

3. If the username already exists, match pass and add google link to account

4. if the username does not exists, create a new with this pass and google link it

5. afterwards, the user wants to login with ORCID

6. if ORCID is new, require a username/pass

7. by using the user/pass from step 2), ORCID is linked into this account, instead of creating a new one

if ORCID/Google token already are in the database, the next logins are going to be smooth.

Another possible approach, to avoid passwords, is:

1. Login with Google
2. If google token is new, require a username
3. If the username already exists, request an e-mail confirmation to link google into the openneuro account
4. if the username does not exists, create a new user and link w google

if the user is unable to use the google sign-in for an already-google-linked openneuro account (i.e. China), he/she/it can request a one-time-login link to his/her/its e-mail.

also, a page to manage (add/remove) linking to other strategies would be cool!

[nellh]

Yeah, the issue is our database schema for relating resources to users. Passport makes it easier to add the challenge step for each provider but doesn't implement the rest. I think there's also a case for supporting multiple Google accounts per OpenNeuro account, less for ORCID.

We should avoid passwords, a username may be a good idea so a user has a unique way to find their account that isn't the email (may change) or a big UUID string. They could set it on first login or initiate adding the new provider account to an existing OpenNeuro account and we could suggest any accounts with matching emails.

An account page listing the linked accounts will be needed so users can add new ones or remove a linked account.

[nellh]

The new plan for this is to phase out Google accounts by asking new Google logins to add an ORCID login and use that moving forward.