Amazon Cognito throws an error if I try to sign in a second time with social sign in (Google/Oauth)

user_13387893 0
Viewed 640

I am writing here to ask for help or at least a clarification.

I work at a startup and a couple of weeks ago we launched our SaaS. We manage all our users with Aws Cognito. I'm using amazon-cognito-identity-js for the authentication on the frontend and both sign-up and sign-in work fine. We want to add social sign-in (OAuth) through Google and for that I'm using aws-amplify-js, calling Auth.federatedSignIn({provider: 'Google'}) as specified in Amplify docs.

The first time a user sign in with Google, a new user is correctly created in Cognito, but if I try to sign in again with the same user I get the following error: #error_description=Invalid+user+attributes%3A+email%3A+Attribute+cannot+be+updated.%0A+&error=invalid_request.

Apparently this is a rather common issue:

After looking for a solution I believe this happens because when we created our User Pool we set email as a required attribute and it was automatically set as immutable. Apparently if you want to use social sign-in every attribute should be mutable (as specified here because on every new sign in Cognito tries to update them.

So now we're stuck. It's not possible to change email attribute from immutable to mutable for an existing User Pool and as far as I know it's not possible to prevent Auth.federatedSignIn({provider: 'Google'}) to update every user attributes.

We cannot simply delete and recreate our User Pool because we're already in production and we got several users already registered. Is there any possible solution or workaround to fix this? Any kind of suggestion would be very helpful!

aws-amplify amazon-cognito amazon-web-services
1 Answers

As of now there is nothing more you could do then to migrate all the users to another User Pool.

For users using federated sign in this won't change anything. You don't store their passwords so they won't see any difference.

The problem starts with users for which you has passwords. While you can migrate them to another pool, they will have to set up a new password.

You could write a simple script that could create a CSV file with the user data and then use the import function of the new User Pool to import all users. All non-federate users will then need to set new password.

You can just notify all of them that this will be happening because the whole operation will involve some downtime (since you don't want the two pools to get out of sync).

user_47379240
Related