Copyright 2017-2018 Jason Ross, All Rights Reserved

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

When you create a user in an AWS user pool using the AdminCreateUser API action, the email address you provide is not automatically flagged as verified. None of the lambdas that are called by other user creation or sign-up methods get called either.

Without a verified email address, users cannot change their passwords again after changing from their temporary passwords which are assigned when the account is created. What do you do?

This isn't really too much of a problem, and the answer is even mentioned in the AWS documentation - either set the email_verified attribute to True in the call to AdminCreateUser, or use AdminUpdateUserAttributes to do the same thing.

When you do this, you may see some strange behaviour, something like the following:

Say you're working on a system with three accounts: Victoria, Edward and George. None of them have verified email addresses, so you decide to set them.

First you set Victoria's account email_verified attribute to True. You display the contents of the user pool and see that everything looks as it should, with Victoria's email_verified attribute definitely set to True.

Next you set Edward's account email_verified attribute to True. You refresh the display of the contents of the user pool and see that Edward's email_verified attribute is set to True, but strangely Victoria's is now False.

For some reason, it looks like your call to AdminUpdateUserAttributes or admin-update-user-attributes changed a value on the wrong user; trying to set the email_verified attribute to True on one user has set the email_verified attribute to False on another user.

Just to make sure, you set George's account email_verified attribute to True. Refreshing the display of the contents of the user pool you see that George's email_verified attribute is set to True, but Victoria's AND Edward's email_verified attributes are now False. Once again it looks like AdminUpdateUserAttributes or admin-update-user-attributes changed the wrong user's attribute to the wrong value.

The reason I've found for this happening is that the user pool containing your users is configured to allow multiple users to be registered with the same email address. This can be useful for development and testing, but can cause problems. If multiple user accounts all share the same email, then you'll get the problem described here - only one account with any given email address can have its email_verified attribute set to True, and trying to set more than one will set all of the others to False.

To avoid these problems, ensure that each user in your Cognito user pool has a unique email address.