Cognito external provider user email cannot be automatically verified

0

According to this documentation, my pre-sign up lambda function handler written in Python is already setting the autoVerifyEmail in the response attribute to True, yet after a user logs in with a external provider of a Active Directory Federation Service using SAML, the user is created in the user pool, but yet the email remains unverified.

Here is the event object from cloudwatch with sensitive data being replaced with '--' for the purpose of this post:

{
    "version": "1",
    "region": "ap-southeast-1",
    "userPoolId": "--",
    "userName": "--",
    "callerContext": {
        "awsSdkVersion": "aws-sdk-unknown-unknown",
        "clientId": "--"
    },
    "triggerSource": "PreSignUp_ExternalProvider",
    "request": {
        "userAttributes": {
            "email_verified": "false",
            "cognito:email_alias": "",
            "cognito:phone_number_alias": "",
            "given_name": "--",
            "family_name": "--",
            "email": "--"
        },
        "validationData": {}
    },
    "response": {
        "autoConfirmUser": true,
        "autoVerifyEmail": true,
        "autoVerifyPhone": false
    }
}

Thank you in advance for any solution to this problem!

1 Answer
0

Prior to discussion about Pre sign-up Lambda trigger, I would first like to mention some details around the integration of Cognito with External identity providers (such as Facebook/Google/Apple/Azure):

→ When a user is created in Cognito after Sign-up using these social providers, all the attributes of the user depend upon the attribute mapping which is configured in Cognito (under the “Attribute Mapping” tab in Cognito User pool console).

→ External identity users on SignIn are automatically confirmed by the Cognito service & the account status is set to "EXTERNAL_PROVIDER" (there is no need of using any Lambda trigger).

→ On every federation i.e. each time the user sign-in, all the attributes of this user are again updated in the user pool based on all the attributes which are sent from the social provider side & also the attribute mapping configured in Cognito.

→ If there is no mapping configuration for email_verified in Cognito for that provider, then upon the federation of your user, this attribute is set to a default value of false.

For more details around mapping in user pool, please refer this documentation link


Now coming to the Pre sign-up Lambda trigger, please note that the trigger is indeed called each time a user sign-up using any of the external providers. However, the values returned by the trigger to verify phone & email are not considered for the federated identities. Hence, this is the reason you are observing this behaviour, where even after returning “autoVerifyEmail = true”, the email_verified is set to false. Though it would work perfectly fine for the native Cognito user which signed-up using username & password.

That been shared, Pre sign-up Lambda trigger cannot be used for your use-case.

In regard to your use-case, there can be two workarounds:

Please refer to “Option 1“ in case if you just want to map the actual value of email_verified attribute for the user, which can be true or false depending upon what is configured for that user at the social provider end. However, in case if you want to make the value for the email_verified attribute to be always true, then please refer to the ”Option 2“.

OPTION 1

In this case, we may use the Attribute Mapping section (for example, "Federation" → "Attribute Mapping" → "SAML") for the user pool to ensure that all the required attribute which needs to present on the user are configured. Hence, in this scenario, we will create a mapping between "email_verified" attribute which is coming from the federated identity provider side & the one present in Cognito. Once that is done for each identity provider, the user created in the user pool will have a value for "email_verified" attribute to be true or false, depending upon what is sent by the provider.

For more details around configuring the attribute mappings for your user pool, please refer the documentation link

Please note, we may use the "Discovery endpoint" of the respective social provider to confirm if it will return a value of “email_verified” or not

OPTION 2

As mentioned earlier in the response that each time the user sign-in with any external provider, all the attributes of this user are again updated in the user pool based on all the attributes values which are sent from the identity provider side. Hence, setting the “email_verified” attribute before authentication using any trigger would lead to no effect, as immediately after signing-in the attribute will be updated to either its default value or to a value coming from the provider side.

Hence, for this solution, we may use the following two Lambda triggers along with the “AdminUpdateUserAttributes” API call which will be used to update the “email_verified” to true during the respective SignUp or SignIn flow:

a) Post confirmation Lambda Trigger: This trigger is the one which is invoked only during the SignUp flow when the user is confirmed, however before the tokens are being issued for the first time. Hence, this trigger will allow us to set the “email_verified” attribute to true before the tokens are issued during the SignUp flow. So, once the token is issued, you will be able to view the same in the Id token as well as in the user details page in the user pool console. For more details around this trigger, please refer to the documentation link

b) Post authentication Lambda Trigger: This trigger is invoked after the user is authenticated during the SignIn flow, however before tokens are issued for the user. Hence, each time when the user sign-in, this trigger will allow us to set the “email_verified” attribute to true before the tokens are issued. Again, to confirm the same, you can either decode the Id token or refer to the user details page in the console. For more details around this trigger, please refer to the documentation link

I hope the above information resolves your query.

profile pictureAWS
SUPPORT ENGINEER
Varun
answered a year ago
  • Hi Varun,

    Thank you very much for your answer. It has given me the explanation as to why the email was not automatically verified.

    As for the solution, I am currently attempting Option 2 while calling the AdminUpdateUserAttributes API within the Post Confirmation lambda trigger function. The issue I've been facing with this option however, is that although I'm following this documentation and calling with the right arguments, I'm not able to get a response from the cognito-idp client, as well as no errors being thrown when calling this API.

    Please advise if possible. Thank you again!

  • I would advise you to log the events in the lambda code and check Cloudwatch logs to investigate what is happening in the background.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions