Amazon Cognito Hosted UI - Merge users from different providers on registration

[Eisman111]

Which Category is your question related to?
Authentication

What AWS Services are you utilizing?
Amazon Cognito Hosted UI

Is your feature request related to a problem? Please describe.
Our app use the Amazon Cognito Hosted UI configured to handle Authentication by email and social (facebook and google). When a user is registered with a social and then try to register with facebook or the native cognito user it will create a new user giving it a different token to connect to other aws services.

Describe the solution you'd like
I have seen the solution with the AdminLinkProviderForUser, the problem is that it doesn't work if the flow is inverted, it would good if we can use it in every possible scenario. Also, when the user log in he will mantain the same token so that for examples files in the S3 bucket would be still be accessible.

Describe alternatives you've considered
For now we will look into preventing user registrations with the same email address

Thanks,
Best regards

[harrysolovay]

Hi @Eisman111 –– this is possible today, just not through Amplify. I don't believe an Amplify abstraction of this feature is coming out of the woodworks soon, but here's how you can achieve what you'd like, today:

Configure a Cognito User Pool post-confirmation Lambda trigger, which does the following:

1. Execute a list users requests with the filter of email = "${event.request.userAttributes.email}"

const listUsersResponse = await cognitoIdentityServiceProvider.listUsers({
  UserPoolId: event.userPoolId,
  Filter: `email = "${event.request.userAttributes.email}"`,
}).promise();

2. If there is a user within the response (if (listUsersResponse.Users.length > 0)), search for two users: one whose UserStatus is "EXTERNAL_PROVIDER", and one whose UserStatus is "CONFIRMED"... although you could also opt to look for "UNCONFIRMED", or various others. It comes down to preference. What merits a user to which you'd want to link the federated user?

const socialUser = listUsersResponse.Users.find((value) => value.UserStatus === 'EXTERNAL_PROVIDER');
// Make sure to decide on the right-hand of the `!==` –– I'd recommend looking only for `CONFIRMED`
const nativeUser = listUsersResponse.Users.find((value) => value.UserStatus !== 'EXTERNAL_PROVIDER');

4. Link the federated user to the native (User Pool) user.

await cognitoIdentityServiceProvider.adminLinkProviderForUser({
  UserPoolId: event.userPoolId,
  SourceUser: {
    ProviderAttributeName: 'Cognito_Subject',
      ProviderAttributeValue: providerUserId,
      ProviderName: providerName,
    },
    DestinationUser: {
      ProviderAttributeValue: nativeUser.Username,
      ProviderName: 'Cognito',
    },
}).promise();

& that sums it up!

Please let me know if you encounter issues. If all goes smoothly, please close this issue out at your leisure.

[Eisman111]

Hi @harrysolovay, thank you for the feedback!

I tried with the adminLinkProviderForUser functionality but didn't put too much focus on it since I read from the documentation that only works when the external provider has not been created yet, but if you say I can use this I'll try again!
Doc: https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminLinkProviderForUser.html

This allows you to create a link from the existing user account to an external federated user identity that has not yet been used to sign in, so that the federated user identity can be used to sign in as the existing user account.

Furthermore, if I merge two users does it means they will only have one id right?

Thank you for your time!

[toddb]

I think these links are also related:

• This article provides an implementation with existing functionality.
• This stackoverflow touches on same API
• and here

[agoldis]

Nope, doesn't work. Linking a federated signed up user to a native congito user throws:

Merging is not currently supported, provide a SourceUser that has not been signed up in order to link

[tannerabread]

Closing this as a duplicate of #5104 so that we can consolidate efforts for tracking this feature-request