amplify-js: Federated sign up doesn't set email_verified to true

@ionutmiftode I actually did! Its not the way I would have chosen in the first place, but for my app it actually works perfect:

The key is too use a “post confirmation trigger” and set the attribute through the AWS SDK itself (adminUpdateUserAttributes Method). The following code works for me:

var aws = require('aws-sdk');
aws.config.update({region: 'eu-central-1'});
exports.handler = (event, context, callback) => {
    if (event.request.userAttributes.email) {
        if (event.request.userAttributes["cognito:user_status"] === "EXTERNAL_PROVIDER") {
            const cognitoIdServiceProvider = new aws.CognitoIdentityServiceProvider({
                apiVersion: '2016-04-18',
                region: 'eu-central-1'
            });
            var params =  {
                UserAttributes: [
                  {
                      Name: "email_verified",
                      Value: "true"
                  }
                ],
                UserPoolId: event.userPoolId,
                Username: event.userName
            }
   
            cognitoIdServiceProvider.adminUpdateUserAttributes(params, function(err, data) {
              if (err) {
                    callback(null, event);
              } else {
                    callback(null, event);
              }
            });
        } else {
            callback(null, event);
        }
    } else {
        callback(null, event);
    }
};

What it does is: After the user authenticates successfully via federation, the post confirmation trigger is always invoked. At this point in time, the user fully exists within the user pool and can be updated through the AWS SDK for cognito. That means, that from within the Lambda function above, I use the cognito SDK itself to update the user and set the “email_verified”-Attribute through the adminUpdateUserAttributes()-Method. I do this only for federated users (user_status === EXTERNAL_PROVIDER), since I don’t want to mess with the already working post confirmation workflow for users that are registering via email. The trigger also seems to be updating the attribute through the SDK fast enough so that my App (React Native in my case) does not even try to send the user to the “verify email”-Screen. This is exactly the behavior I was hoping for. Keep in mind that your lambda execution role needs the “cognito-idp:AdminUpdateUserAttributes” permission to update the attributes through the SDK.

We rolled out this solution to production on May 10th and haven’t had any issues with it since and noticed around 30 user registrations via Facebook and Apple without any complaints.

While this is working I still don’t understand why we have to go this route. Having to verify the users email address if the users comes from a federated service does not make sense to me at all.

I hope this solution works for you as well! Feel free to contact me if you need any help 😃

I was running into the same problem because I didn’t notice that there is a “email_verified” attribute on Googles side to map to. This fixed my problems with the Google IDP, thank you!

But how do you set the email_verified attribute for Facebook, Apple or any other IDP that does not offer the email_verified attribute? I am currently implementing social logins into my React Native app using the Amplify HOC. Without the email_verified attribute, the user is always redirected to the verifyContact-Component where the confirmation code, which usually gets send via email, should be entered. Using social logins, this is not the desired behaviour.

I have not been able to find documentation on this when using federated logins and the amplify HOC. Any help would be very appreciated.

FYI @timoschlueter , @ionutmiftode :

Thank you for sharing the detailed use-case.

Using our internal tools, I found that there is an ongoing feature request for the ability to set “email_verified” to true via Cognito console. I have gone ahead and added your voice to the feature request. However please understand, being from Premium Support, I do not have visibility regarding service team’s product roadmap and backlog and therefore, will not be able to provide an ETA as to when the feature will be released. As soon as it gets released, it should be publicly announced in either [1][2].

Amazon Cognito invokes Post Authentication trigger after signing in a user, allowing you to add custom logic after authentication. Until the feature is released, you can update “email_verified” attribute using “AdminUpdateUserAttributes” API in a Post Authentication trigger which you have already implemented. Please note once the user has sign-up, this trigger will be executed for every future successful sign-in.

So looks like our path forward is the right one (for now), and hopefully they move forward on the roadmap item at somepoint.

❤️

For those who discover this issue via Google, here are the related Cognito docs:

Specifying Identity Provider Attribute Mappings for Your User Pool (AWS Management Console)

Example app:

@ionutmiftode , 😃 awesome

@timoschlueter , totally agree, a bunch of Cognito aspects seem unfinished (or atleast unpolished). I have a support case open with Amazon, if I get any headway there, I’ll update the thread.

@ionutmiftode I actually did! Its not the way I would have chosen in the first place, but for my app it actually works perfect:

The key is too use a “post confirmation trigger” and set the attribute through the AWS SDK itself (adminUpdateUserAttributes Method). The following code works for me:

var aws = require('aws-sdk');
aws.config.update({region: 'eu-central-1'});
exports.handler = (event, context, callback) => {
    if (event.request.userAttributes.email) {
        if (event.request.userAttributes["cognito:user_status"] === "EXTERNAL_PROVIDER") {
            const cognitoIdServiceProvider = new aws.CognitoIdentityServiceProvider({
                apiVersion: '2016-04-18',
                region: 'eu-central-1'
            });
            var params =  {
                UserAttributes: [
                  {
                      Name: "email_verified",
                      Value: "true"
                  }
                ],
                UserPoolId: event.userPoolId,
                Username: event.userName
            }
   
            cognitoIdServiceProvider.adminUpdateUserAttributes(params, function(err, data) {
              if (err) {
                    callback(null, event);
              } else {
                    callback(null, event);
              }
            });
        } else {
            callback(null, event);
        }
    } else {
        callback(null, event);
    }
};

What it does is: After the user authenticates successfully via federation, the post confirmation trigger is always invoked. At this point in time, the user fully exists within the user pool and can be updated through the AWS SDK for cognito. That means, that from within the Lambda function above, I use the cognito SDK itself to update the user and set the “email_verified”-Attribute through the adminUpdateUserAttributes()-Method. I do this only for federated users (user_status === EXTERNAL_PROVIDER), since I don’t want to mess with the already working post confirmation workflow for users that are registering via email. The trigger also seems to be updating the attribute through the SDK fast enough so that my App (React Native in my case) does not even try to send the user to the “verify email”-Screen. This is exactly the behavior I was hoping for. Keep in mind that your lambda execution role needs the “cognito-idp:AdminUpdateUserAttributes” permission to update the attributes through the SDK.

We rolled out this solution to production on May 10th and haven’t had any issues with it since and noticed around 30 user registrations via Facebook and Apple without any complaints.

While this is working I still don’t understand why we have to go this route. Having to verify the users email address if the users comes from a federated service does not make sense to me at all.

I hope this solution works for you as well! Feel free to contact me if you need any help 😃

Thank you so much!

FYI: @timoschlueter and @ionutmiftode

• We seemed to have a race condition with the linking of ExternalProvider to Native Account when we used Post Confirmation and we also accidentally would trigger it with a Confirm Forgot Password.
• We ended up putting ours in Post Authentication to always keep the Native Account in sync as email_verified = ‘true’

Real pain in the rear ❤️, Bradley

I ran into the same issue. I even tried using the pre-signup trigger with autoVerifyEmail and autoVerifyPhone set to true. That didn’t work either. @timoschlueter’s suggestion to use post-confirmation worked. Thanks!

@HMilbradt Well It is not a Amplify bug directly BUT I agree completly with you about the stupidity of this.

Even when you use the presignup trigger with autoVerifyEmail to true, which is what we should do for this kind of tricks, it does not work… In this case it is literraly a bug (https://docs.amazonaws.cn/en_us/cognito/latest/developerguide/user-pool-lambda-pre-sign-up.html#aws-lambda-triggers-pre-registration-example-2) So here we are, we have to hack the given hack.

Hi @slatted @timoschlueter,

How did you write refreshHandlers for Google, Facebook or Apple? I know that is not related to this problem but I cannot find any reliable solution 😦

We currently “don’t” for Social. If a user logins with a native account, it will properly use the refreshToken to regain access as the user, but we hit a wall with Social, and our use case didn’t really require it, so if someone uses Social they just single click next time if logged out.

TY @slatted We ended up using both Post Authentication and Post Confirmation to solve the problem 😄

@slatted because of your finding I just checked our Cognito user pool and indeed found a few external users (< 10%) with email_verified still set to false. I haven’t noticed this before. Thanks for the info! I switched to a Post Authentication trigger as you suggested. Still seems to work as expected.

Really looks like a race condition.

I can’t stress this enough: The fact that we have to use such a hack in the first place is really frustrating. 😦

@timoschlueter used your solution, works as expected! I also fixed the profile picture issue here which is great!

One more thing, I added the logic in ‘Post Authentication’ lambda trigger, but this one is called when user sign in, not when he sign up, so I think the logic should be added in a Post Sign-up lambda trigger, but there is no such option.

the options from amplify cli for lambda trigger are:

• Create Auth Challenge
• Custom Message
• Define Auth Challenge
• Post Authentication
• Post Confirmation
• Pre Authentication
• Pre Sign-up
• Verify Auth Challenge Response
• Pre Token Generation

Any idea which one I should use? Thanks

EDIT: So the winner is Post Confirmation 😄

@ionutmiftode unfortunately not. Our app uses just the email address 😦

@tim

I was running into the same problem because I didn’t notice that there is a “email_verified” attribute on Googles side to map to. This fixed my problems with the Google IDP, thank you!

But how do you set the email_verified attribute for Facebook, Apple or any other IDP that does not offer the email_verified attribute? I am currently implementing social logins into my React Native app using the Amplify HOC. Without the email_verified attribute, the user is always redirected to the verifyContact-Component where the confirmation code, which usually gets send via email, should be entered. Using social logins, this is not the desired behaviour.

I have not been able to find documentation on this when using federated logins and the amplify HOC. Any help would be very appreciated.

Did you managed to verify the email address from facebook?

I have the same issue, using react native, google works fine but facebook requires an extra step to have the email verified

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

@elledienne Circling back, still waiting to hear from Amazon Cognito on this, apologizes on the delay.

@sammartinez Thanks a lot for your prompt answer, happy to support with testing/ experiment if that’s helpful 😃