Skip to content

Why is email_verified still false for Facebook users in Amazon Cognito even after setting autoVerifyEmail = true

0

I'm using Amazon Cognito User Pools with Facebook as a federated identity provider. The login flow works, and users are created successfully. However, users signing in through Facebook are always created with: "email_verified": false, This causes issues in parts of our app that depend on the email_verified flag.

What I’ve tried so far:

  • Used a PreSignUp Lambda Trigger :
  1. I detect Facebook logins via userName.startsWith('Facebook_')
event.response.autoConfirmUser = true;
event.response.autoVerifyEmail = true;

  • Confirmed This Is Due to Facebook Response
  1. So even when I try to override it in PreSignUp, Cognito ignores the autoVerifyEmail = true setting.

  • Added a PostConfirmation Lambda Trigger
  1. After sign-up confirmation, I use the AWS SDK to manually update the user:
const client = new CognitoIdentityProviderClient();
await client.send(
  new AdminUpdateUserAttributesCommand({
    UserPoolId: event.userPoolId,
    Username: event.userName,
    UserAttributes: [
      { Name: 'email_verified', Value: 'true' }
    ]
  })
);

This code runs successfully, logs indicate the update is applied, and there are no errors. Yet when I check the user in the Cognito console after login, the email_verified attribute is still false.

2 Answers
0

The issue you're experiencing with Facebook users having "email_verified" set to false in Amazon Cognito, even after attempting various solutions, is a known behavior when using federated identity providers like Facebook.

When users sign in through Facebook, Cognito creates a user profile based on the information received from Facebook. However, Cognito does not automatically verify the email address provided by Facebook. This is because Cognito cannot guarantee that the email address from Facebook has been verified by Facebook itself.

The PreSignUp Lambda trigger approach you've tried doesn't work for federated users because the autoVerifyEmail flag is specifically for users signing up directly through Cognito, not for federated users.

Your PostConfirmation Lambda trigger approach should theoretically work, but there might be a timing issue or a caching problem that's preventing the change from being immediately visible in the Cognito console.

Here are a few potential solutions you can try:

  1. Instead of relying on the email_verified attribute, you could create a custom attribute to indicate that the user has signed in through Facebook, and use that as a proxy for email verification in your app logic.

  2. Implement a custom flow where, after the initial Facebook sign-in, you prompt the user to verify their email address through Cognito's built-in verification process.

  3. Use the AdminUpdateUserAttributes API call in your application code after a successful Facebook login, rather than in a Lambda trigger. This might help avoid any potential timing or caching issues.

  4. If you're certain that Facebook has verified the email address, you could implement a solution where you set email_verified to true for all Facebook users in your application logic, rather than relying on Cognito to do it automatically.

Remember, while these approaches can help manage the issue, they come with their own security considerations. Always ensure you're following best practices for user authentication and verification in your specific use case.
Sources
Pre sign-up Lambda trigger - Amazon Cognito
Configuring email or phone verification - Amazon Cognito

answered a year ago
-1

Based on the information you've provided, here is the explanation:

  1. Cognito Behavior with Facebook: It's a known behavior that Cognito sets 'email_verified' to false for Facebook logins, even when the email is verified on Facebook's side. This is because Cognito cannot independently verify the email address provided by Facebook.

  2. PreSignUp Lambda Trigger: Your approach of using a PreSignUp trigger is correct, but as you've noticed, setting 'autoVerifyEmail' to true doesn't work for federated logins. This is by design, as Cognito doesn't allow overriding this attribute for external providers.

  3. PostConfirmation Lambda Trigger: Your approach here is also correct, and it should work. The fact that it's not working suggests there might be an issue elsewhere. Let's explore some possibilities:

    a. Timing: There might be a race condition where your manual update is being overwritten by a subsequent process. Try adding a small delay before updating the attribute.

    b. Permissions: Ensure that your Lambda function has the necessary IAM permissions to update user attributes.

    c. User Pool Client Settings: Check if your User Pool client has the 'email' scope enabled for Facebook login.

  4. Alternative Solutions:

    a. Custom Claims: Instead of relying on the 'email_verified' attribute, you could create a custom attribute (e.g., 'custom:email_verified') and set it to true for Facebook logins. Then, modify your application to check this custom attribute instead.

    b. Post Authentication Trigger: Try using a Post Authentication trigger instead of Post Confirmation. This trigger fires after every successful authentication, allowing you to update the user attributes.

    c. Token Custom Claims: You could add a custom claim to the ID token that indicates the email is verified for Facebook logins. This would require modifying your application to check this claim instead of the 'email_verified' attribute.

Remember to thoroughly test any solution you implement, especially considering the security implications of marking an email as verified.

AWS
answered a year ago

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.