amplify-js: Cognito: unable to login with email if user attempts to update email address

Finally solved this issue with a sneaky workaround and only few lines of code !! 🎉🎉

The goal is keeping the attributes unchanged until they are verified. In my case there is a sign in with phone number only and users can update their phone number and logout without verifying.

If anyone is interested here is how I did it STEP BY STEP —>

STEP 0: Custom attribute and lambda trigger for Custom Message

I introduce another attribute (called custom:validated_phone) and a cognito custom message lambda trigger for CustomMessage_UpdateUserAttribute

STEP 1: Updating user attributes with new phone number

When user wants to update their phone number client sends the current (already validated ) phone number in custom:validated_phone in updateUserAttributes function.

const result = await Auth.updateUserAttributes(cognitoUser, {
    phone_number: NEW_PHONE_NUMBER,
    'custom:validated_phone': CURRENTLY_VALIDATED_OLD_NUMBER,
  });

So cognito changes the phone_number attribute with the new one. This is something I dont want, because it isn’t validated yet

Here comes the sneaky trick. Before cognito sends user a verification code it triggers a lambda to customize the message. In this lambda I look at the attribute custom:validated_phone and as an admin I update phone_number attribute back to original one (validated one). So until there is verified phone number the old one will be the still only one the in the system

if (event.triggerSource === 'CustomMessage_UpdateUserAttribute') {
  const validated_number = event.request.userAttributes['custom:validated_phone'];
  const params: AdminUpdateUserAttributesRequest = {
    UserAttributes: [
      {
        Name: 'phone_number_verified',
        Value: 'true',
      },
      {
        Name: 'phone_number',
        Value: validated_number,
      },
    ],
    UserPoolId: event.userPoolId,
    Username: event.userName,
  };
  const result = await cognitoIdServiceProvider.adminUpdateUserAttributes(params).promise();
  if (validated_number === event.request.userAttributes.phone_number) {
    throw new Error('failed to prevent sending unnecessary verification code');
  }
}

STEP 2: Verifying new phone number

After STEP 2 user still gets a verification code to his new number. The client then verifies the code. If the verification is successful then this time I again call updateUserAttributes with new number as custom:validated_phone. Because its now verified

const result = await Auth.verifyUserAttributeSubmit(cognitoUser, 'phone_number', code);
if (result === 'SUCCESS') {
  const result2 = await Auth.updateUserAttributes(cognitoUser, {
    phone_number: NEW_PHONE_NUMBER,
    'custom:validated_phone': NEW_PHONE_NUMBER,
  });
}

Now again my lambda trigger but this time both attributes are equal to each other, therefore after updating this real phone_number attribute I fail lambda intentionally so another verification code isn’t sent again

  if (validated_number === event.request.userAttributes.phone_number) {
    throw new Error('failed to prevent sending unnecessary verification code');
  }

Conclusion:

I know its tricky but much better than setting up your own verification method with DynamoDB etc… Hope it helps.

Hi all,

I’m on the Cognito team and apologize that we haven’t commented on this thread sooner. We have been hearing the feedback. Lots of points to touch on here.

As you may know, there are two basic ways to allow users to sign in with an email address with Cognito User Pools. The originally supported way involved requiring separate usernames and email addresses for users, and once the email address was verified, it could be used in place of the username for signing in the user. In the Cognito Console on the Attributes tab, this approach is described as “Username - Users can use a username and optionally multiple alternatives to sign up and sign in.” One of the issues with that method (as clintfoster did describe) is that users can no longer sign in via email if they change their email and don’t verify it. They can still sign in by username, but users may not know their username. The crux here is that email addresses can only be used to sign in once they have been verified. We built it that way so someone else cannot claim an email address that does not belong to them. They can create an account entering someone else’s email address, but they won’t be able to sign in with it, and it won’t prevent the real email owner from creating an account and verifying and then using his/her email address.

Due to that issue with changed but unverified email addresses, and because often there is no need for a separate username, we added a second approach for signing in via email (or phone number). With this second approach, you don’t use separate usernames and email addresses, and instead you provide the email address as the username, and Cognito uses it as an email address. In the Cognito Console on the Attributes tab, this approach is described as “Email address or phone number - Users can use an email address or phone number as their “username” to sign up and sign in.” With this approach users can still sign in with their email address after they have changed it even if it has not been verified.

Some description of these two approaches in here in the Cognito User Guide.

We also recognize that, as has also been called out, it would be an improvement to not change the email address until after it is verified. We do have that on a list of issues to address, but I don’t have any timing I can share.

Lastly, I want to clarify the distinction between account confirmation and email/phone verification. When a user first signs up, account confirmation and email verification typically happen at the same time, unless you have a Lambda trigger customizing the behavior. That is, when users first verify an email (or phone), their account is confirmed at the same time that the email (or phone) is marked as verified. When users change their email or phone, their email/phone is marked as not verified, but their account stays confirmed. Thus they can still sign in if they know the right credentials, e.g., a separate username and their password.

I hope all that helps explain the situation. Thanks for the questions and feedback.

Regards, Tim

Hi, I am Amit from the Cognito team. Appreciate you all taking the time and providing valuable feedback. I wanted to let you know that we heard you and know we are continuously adjusting our roadmap balancing our customers’ operational needs against new features requests and enhancements to existing functionality.

That said, we are evaluating a change to address the feedback here (Can’t comment on specific timeline).

Thanks!

How about we don’t call this one stale until we hear some real answers?

2.5+ years and still no solution. Shame

Cognito team or I rather say zombie team, any updates on this? i think it will be very easy to fix. Also i think you should add a paragraph to your cognito getting started guide and name it 1000 reasons why cognito will not suit your business use case and maybe a warning: We are usually not fixing issues, use it at your own risk. cc @timwhunt

@danielgeri I’m having the same issue with the exception of one of your problems. I can change a user’s email address, log out, and can now only log in with the new unverified email. The user is now unable to log in with the old email.

So where this personally has problems is say a user mistakenly enters the wrong email during the change email process, they are now locked out of their account if they sign out and don’t remember their mis-entered email. Given that Cognito has no baked in account recovery or forgot username tools, the user is forced to contact a system admin to fix the issue.

It seems to me that Cognito shouldn’t be updating the user’s email/phone until after the verification process has happened. It would seem to solve both of our issues, provide a more secure system, and not be all that confusing for a user to figure out.

Also experiencing this issue. Cognito, please advise.

Using the aliases in Cognito user pool, only a verified email can sign in. Unfortunately, updating email removes the old verified email and leave the new email not verified. I want to keep the old email in preferred username to continue login before new email verified, but got above error @sloansparger mentioned. As @danielgeri said, which leaves users in a limbo state. Really hope the Cognito team can give an update about this issue.

After using Cognito for a couple of years now and finding it to be reliable and well-designed overall, I would say this is one of the biggest problems with it, bordering on rendering the email alias feature unusable for production. Although it’s a serious issue that is certain to leave some percentage of users locked out of their accounts, unless you’ve dealt with it first-hand, it’s hard to describe in a way that really brings home what’s happening. I did my best in my description here almost 2 years ago (now archived). At that time it was acknowledged as a “service issue” (meaning it’s happening in the cloud, not the client SDK) and marked as a “feature request”. Meanwhile, the GitHub issue got archived when the Cognito JS SDK was replaced with Amplify. So the SDK team has apparently washed their hands of it, and it’s unclear how to get the service team to look at it.

I assume Amazon isn’t “dog-fooding” Cognito since they already had a user management facility before it existed. If they were, this problem would have been addressed by now since dealing with angry users who have been locked out of their accounts has a way of making you look more carefully at an issue that might be hard to describe, but is clearly capable of happening to real users.

Following up with the Cognito service team. Thank you everyone for your patience!

I entered the same issue against the old amazon-cognito-identity-js SDK:

Gap in change email flow when alias exclusively used for sign-in

Even though it’s still open I think it got forgotten when the old SDK was retired. I can see how this happened since most of the issues were probably related to the old SDK, not the Cognito back-end. But it’s really a Cognito back-end issue. Since there isn’t a GitHub project for Cognito itself, the front-end is the only place to enter issues.

I’m officially asking: Do we have a fix?

Not stale…

Allowing a user to change their email address, .esp when their email address is used for sign in, without first confirming the address, seems to me to be a major security flaw. I could be wrong.

At present, a user, if logged on, can change their email address, using Auth.updateUserAttributes, if given the opportunity in the client, after which, there is no control as to whether or not that email address can login or not based on whether or not it as been confirmed.

I’ve written code to allow the user to input the verification code that gets sent by cognito, so as to verify the email address, but it doesn’t matter if the user can log in when the email_verified attribute is false.

It’s not token related either, as I’ve waited an hour for tokens to expire.

Problem: the user can log in, with the new email, when email_verified === false in the user pool.

While this can be programmed around, client-side, I would rather rely on Cognito to prevent this behavior in the first place, as it is inherently insecure.

Prove me wrong, so that we can get a good solution here, please.

I don’t work at Amazon, but the Amazon recruiters wont leave me alone. I am so sick of this issue, so I have asked the L8+ that last tried to hire me to consider re-org-ing the Cognito team, and also pointed them to this thread, citing it as an example of amazons inability to be the kind of place a good engineer wants to work.

I now will reply to every Amazon Recruiters request to connect or that I interview with a link to this thread, from now on, citing the incompetence displayed here as a reason I wont join amazon, until this issue is resolved.

The Cognito team is absolutely failing its customers, every day. They should be ashamed of themselves. So I’m going to intentionally turn up the heat. Eventually, the recruiters will contact their executive and these people will hopefully display some leadership and raise the bar so Cognito will be reorged.

I think you’re right @mfogel, the solution @Can-Sahin proposed opens a way for a user to set any phone number as verified without actually verifying it. However, this is the only working work-around that I’ve found so maybe we just have to accept this security hole to be able to offer users a consistent way to verify a new phone / email.

Really hoping AWS to change the behavior so that changing phone/email attribute is postponed until it’s really verified 🙏 🙏

This can be done by using two steps (I’ve used lambda functions). You can send a code and then set the email back to the original email until the code is confirmed.

I’ve put some example code here:

https://jordizle.com/lab/010be7e1-a34a-4a3c-821e-36f70f3290dc/change-email-with-aws-cognito-and-amplify/

This solution perfectly worked for me and it looks clean also. I wonder why the Cognito team has not implemented this feature internally on their own, so we don’t require to use this type of hack.

@jordizle Good write up, but the problem isn’t that this issue can’t be worked around.

(In my opinion) plenty of the people who have commented here will be able to work around it without much help… fundamentally the problem is that the service shouldn’t have such a glaring issue it in that has been open for 2 years now with no solid resolution.

Any number of work arounds exist to fix the problem as well, the problem you create in doing so is that that (for example at a larger corporate company) these workarounds become hidden knowledge to other developers and hidden knowledge of a problem is inevitably prone to create issues down the road for implementations or be lost with staff turnover and then no one can maintain it. There’s also the additional problem that workarounds can be extremely flaky and small changes to the Cognito could render then inoperative or completely broken with no notice.

It is unbelievably frustrating that something like this can be left unaddressed for such a long time in such a core AWS product - additionally without it being documented, closed or fixed officially by the AWS team.

@jiwabob If I’m understanding correctly there seems to be a pattern here with both Option 1 (email is alias for username) and Option 2 (email is username): Allowing an email address change to proceed in any way on the service side before the user has confirmed it is a bad idea. This harkens back to my earlier quote from @timwhunt:

We also recognize that, as has also been called out, it would be an improvement to not change the email address until after it is verified. We do have that on a list of issues to address, but I don’t have any timing I can share.

Thinking like a programmer, I’m guessing the original service implementation never fully accounted for an intermediate state before the email or phone is confirmed. Doing it properly would require an additional field in the DB to store both the old and new values. I don’t see this issue being properly solved until the service team undertakes the necessary foundational work.

It must be frustrating for the client SDK team to see all the appeals here since there apparently isn’t much they can do to get the service team to look at long-standing problems with large volumes of ongoing activity from many different customers spanning all SDKs.

This can be done by using two steps (I’ve used lambda functions). You can send a code and then set the email back to the original email until the code is confirmed.

I’ve put some example code here:

https://jordizle.com/lab/010be7e1-a34a-4a3c-821e-36f70f3290dc/change-email-with-aws-cognito-and-amplify/

New to using Cognito / Amplify and ran into this issue as well.

Nothing new on my part to add to the discussion, just wanted to show the Cognito team that we’re many facing this issue.

It’s absolutely crazy to me that a company as large as Amazon is unable to find the resources to fix what seems to be a pretty large flaw in their auth ‘solution’… 😕

As @clintfoster said earlier, this borders on rendering the email as username feature unusable.

Hi, I am Amit from the Cognito team. Appreciate you all taking the time and providing valuable feedback. I wanted to let you know that we heard you and know we are continuously adjusting our roadmap balancing our customers’ operational needs against new features requests and enhancements to existing functionality.

That said, we are evaluating a change to address the feedback here (Can’t comment on specific timeline).

Thanks!

As developers, we all know what “evaluating” means. Effort vs ROI. As much as I want to be hopeful, after 3 years, and now it’s in evaluation.

NOT STALE

/// Looks like there isn't a condition YET to break the loop :( 
while(true) {
	notStale();
} 

I ended up leaving this issue for my application. However, I supposed you could build your own email verification for the change email (don’t change email when users submits to change, instead pass it to your own system). Send them a custom made verification link to the new email and let them verify. Once they click the link your API will need manually update their email using the CognitoIdentityServiceProvider.adminUpdateUserAttributes method in the aws-sdk package. Obviously a load of added work to get around this, but pretty sure this would work.

Up

Our solution was to capture email address changes as they happen and then delete and recreate the user with the new email address, therefore forcing them to verify their new email address. It seems like a silly workaround, but it was probably the most straightforward.

On another note, it seems to me that this issue shouldn’t even be an issue long past its discovery (in this case 2 years+) and should be a fundamental part of the flow.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This isn’t stale. I would like to mark amplify-js as stale since there are few issues most people suffer for literally years and still no improvement.

@AWSAmitjh @hkjpotato what do you think by when we can expect his to be fixed?

They have had many many many years so it’s very clear that Amazon simply doesn’t have the kind of engineers that are good enough to be able to fix these issues, because clearly they’ve had over three years to do the work that would take probably less than a week to do with one person.

My trust in the technical capabilities of aws is dwindling fast; any organization that allows one single team to absolutely destroy credibility with customers like this is toxic, and Amazon needs to do something about their Cognito problem.

I’m a developer so naturally when I see someone like you start with the public relations and marketing stuff and get hand wavy, I automatically assume the worst intentions. But OK, let’s give you the benefit of the doubt. Somebody has to be the first person to do that, after all…

So let’s start the healing.

But honestly what you said makes no sense at all so now I’m confused, because an instance of Cognito doesn’t allow us to upgrade it or export or import users or data into/from it; and a lot of the defects that I have reported in multiple tickets are not even things that would create backwards compatibility issues. In many cases these issues that I have reported actively stop users from being able to create instances of Cognito, or they show fundamental security issues that seem like they would be a days work to fix at the most.

From my perspective as a principal level engineer, This specific defect only exists because that team didn’t do their due diligence or care about the user flows enough and this was only one of the issues that created. It’s a symptom of the fact that that team is not at all customer focused and actively refuses to fix issues that are repeatedly reported via customer service channels that users are forced to pay for but then get no resolution with. Effectively that team forces us to pay for support to be allowed to report issues, but that support that we pay for is something we never really get from them.

So I have to ask what you mean here, because this seems really handwavy and that team has a consistently bad reputation for failing customers or creating issues that lead to failed customer expectations; I even had to force them to update their documentation once by pushing really hard as a customer on a bug with support that’s still an active issue to this day and all they would do is update a couple lines in the public documentation but refused to fix the actual issue.

It was not a backwards compatibility issue, not unless their architect sucks. You talk about best practices, but its clear that that team doesn’t use best practices or these issues would never have had to be filed.

So you can see, I’ve got good intentions here and I would honestly be totally open to putting myself out there, but as you can see, my hearts been hurt before.

Hi @duaneking and to all curious about the update on this issue. I am from Amplify team and I am checking with our Cognito partner on this issue. Thank you for your patience and sorry for the wait.

As many pointed out, Amplify as a frontend team, relies on service team (Cognito) for backend API fix/update. What I can share now is this issue is currently in Cognito’s team radar. While Amplify is also waiting for the update from the service team, I wish to share some general concerns for a backend fix like this with you. Hopefully, it can help shed some light on why the fix is challenging and time consuming, and help to get your understanding on the wait 🙏

Following the common best practices, AWS cloud service is designed to be scalable and reliable for our customers. As mentioned in the above discussion, one major challenge for the fix is that it needs to somehow introduce a new “state” in the backend (so as to hold the temporary unverified email). Introducing a new state to an existing service always raises concerns on how to make it scalable (e.g. where and how to effectively and securely store the new state? when to release the resource for storing that temporary state?) and reliable/resilient (e.g. how do we re-populate the state if the service somehow needs a reboot?). Last but not the least, it also needs to care about backward compatibility and consistency. For customers who is good with the current implementation, it needs a mechanism to opt in/out the fix. This then raises the question on how to integrate the fix/feature into the “control plane”(e.g. user pool configuration), to avoid introducing confusion/unexpected behaviors to both existing and new customers.

AWS does care about the customers, and that is why the service team needs to take so many different aspects into account before launching a robust fix, which makes the process slower than expected 🙇

Again I appreciate your patience on it, and will keep update here once I hear more from the service team.

Based on my personal discussions with the amazon support team I can get in contact with, since the defect and security issue tickets I file reporting defects and security issues in cognito are all getting ignored, I assume the cognito team is actively refusing to make security and other fixes because AWS no longer wishes to support customers with cognito as a product, and so I am now working to use a different service/provider. as they cannot be trusted.

I wish AWS would clean that house out and get it working like it should be, Cognito could be such a great service if it was given a good team that actually cared about customers and didn’t just delegate things to external teams so they could be neglected at scale and used as meat shields for customers anger.

Every single issue the cognito team refuses to fix creates more and more customer pain points; and reporting issues does not get anything fixed. I have tickets at multiple startups over the years where I have reported the same exact security issue and yet years later its still not fixed and its still reproducible.

Do we have a regex for valid email id? What is aws cognito using at backend to validate it?

As always, SO is your friend 😃

https://stackoverflow.com/questions/201323/how-to-validate-an-email-address-using-a-regular-expression

because of this bug/vulnerability I had to put our migration to cognito on hold.

is there any update on this?

At present I don’t see any way to securely update the phone/email if either or both are set up as aliases in Cognito. Is there any update on this?

Thanks for the feedback on this everyone. As @harrysolovay has mentioned above, we are raising this to the Amazon Cognito team internally. As others have called out above, we, Amplify are an Open Source project for development of mobile and web applications and not run by the Amazon Cognito team or any specific AWS service team. Can anyone provide the AWS Forums post for this issue? In the meantime, we will provide an update on this once we have one from the service team. Thanks!

If you have the ability to do so, I would go with user pool Option 2, as described here in this same issue by Cognito team member @timwhunt last fall.

As Tim described, the Cognito team solved this problem (sort of) by allowing the username to literally be the email address (instead of having a separate username with an email “alias”). Per the Cognito docs, when you set up a new user pool there are now two choices:

• Option 1 (original way): Email as sign-in alias: With this option the username cannot be an email address. But the email address can be used as an alias for sign-in, once verified. As many people have found after they go to production (sadly), this option will cause some users to be locked out when they change their email address and do not verify it in time. It has no straightforward solution (though many hacks have been discussed in this thread over the years).
• Option 2 (new way): Email as username When signing up, the user is literally allowed to specify their email address as their username. If you did not choose this option when creating your user pool, you’re stuck with the hacks for Option 1 unless you have the luxury of re-creating your user pool from scratch and choosing Option 2.

Having said that, as many here have pointed out, there is a straightforward service-side fix for Option 1. Tim alluded to this as well:

We also recognize that, as has also been called out, it would be an improvement to not change the email address until after it is verified. We do have that on a list of issues to address, but I don’t have any timing I can share.

AWS should implement this fix if Option 1 is still supported. They should also consider those of us who have deployed large user pools with active customers who cannot easily migrate to Option 2 without requiring all users to create new accounts. The number of people still chiming in here after almost 3 years is surely sufficient evidence that this is a significant problem.

It seems doubtful that AWS is working on this, but It’s hard to know since the service component of Cognito does not have a GitHub project where discussion can take place. Everyone is talking about it here because it’s the only option.

For reference, here is the old issue that was archived when the old Cognito JS SDK was deprecated.

Could someone on the Cognito team try reproducing this with the three steps I outlined in the same issue against the original Cognito JS SDK almost two years ago…?

Gap in change email flow when alias exclusively used for sign-in

You have to wait until the verification code expires to see it (step 2). But this is a scenario that commonly happens with real users. They get distracted and they don’t enter the code right away. Then they are locked out because they cannot sign in with their old email alias, nor can they sign in with the new one.

I have once again presented this defect to yet another hiring manager at amazon/aws.

I was contacted today by people internal at AWS, and I sent them this bug link exactly as I said I would in my earlier post.

@duaneking I am sorry to hear that, and I am not trying to do public relations. I am also a developer, like many of us, waiting on the fix of this issue.

My intention is just to share what I learn from the Cognito service team. As a frontend developer, I was also curious why it took such a long time for fixing it in backend. Those concerns mentioned above are what I learned (and what I can share), and I find them helpful for me to understand the challenges they are facing. So I think it might be a good idea to share them (while we are waiting together). Other than that, I could not speak too much for the Cognito service team until I get new update from them.

1. Use updateUserAttributes to change email
2. Use verifyCurrentUserAttributeSubmit to submit the verification code email to the user (this is sent automatically when updateUserAttributes email is called with email)

• use verifyCurrentUserAttribute to resend verification codes

After calling the initial updateUserAttributes with the new email, show a verification UI which calls verifyCurrentUserAttributeSubmit after the user enters their code. Ideally, the user will enter the code then and the new email will be verified. However, if the user signs out before performing that step:

A. Log in with the old email will fail B. Log in with new email succeeds but directed to verification step to enter verification code

@clintfoster What we’ve seen is that if the user changes their email address (which IS the username as you say), but doesn’t confirm it, their email is updated, and they are able to log in with the new email address regardless of the new email’s confirmation status. This becomes an issue if the user entered the wrong email address, as they would no longer be able to log in. What I believe should happen is that until the user verifies the new email address, the email address is NOT updated (when Option 2 anyway, where the email address is the username).

Kind of ridiculous this issue has been open for almost a year and no response from Cognito/Amplify team…I am also curious about this.

Finally solved this issue with a sneaky workaround and only few lines of code !! 🎉🎉

The goal is keeping the attributes unchanged until they are verified. In my case there is a sign in with phone number only and users can update their phone number and logout without verifying.

If anyone is interested here is how I did it STEP BY STEP —>

STEP 0: Custom attribute and lambda trigger for Custom Message

I introduce another attribute (called custom:validated_phone) and a cognito custom message lambda trigger for CustomMessage_UpdateUserAttribute

STEP 1: Updating user attributes with new phone number

When user wants to update their phone number client sends the current (already validated

) phone number in custom:validated_phone in updateUserAttributes function.

const result = await Auth.updateUserAttributes(cognitoUser, {

    phone_number: NEW_PHONE_NUMBER,

    'custom:validated_phone': CURRENTLY_VALIDATED_OLD_NUMBER,

  });

So cognito changes the phone_number attribute with the new one. This is something I dont want, because it isn’t validated yet

Here comes the sneaky trick. Before cognito sends user a verification code it triggers a lambda to customize the message. In this lambda I look at the attribute custom:validated_phone and as an admin I update phone_number attribute back to original one (validated one). So until there is verified phone number the old one will be the still only one the in the system

if (event.triggerSource === 'CustomMessage_UpdateUserAttribute') {

  const validated_number = event.request.userAttributes['custom:validated_phone'];

  const params: AdminUpdateUserAttributesRequest = {

    UserAttributes: [

      {

        Name: 'phone_number_verified',

        Value: 'true',

      },

      {

        Name: 'phone_number',

        Value: validated_number,

      },

    ],

    UserPoolId: event.userPoolId,

    Username: event.userName,

  };

  const result = await cognitoIdServiceProvider.adminUpdateUserAttributes(params).promise();

  if (validated_number === event.request.userAttributes.phone_number) {

    throw new Error('failed to prevent sending unnecessary verification code');

  }

}

STEP 2: Verifying new phone number

After STEP 2 user still gets a verification code to his new number. The client then verifies the code. If the verification is successful then this time I again call updateUserAttributes with new number as custom:validated_phone. Because its now verified

const result = await Auth.verifyUserAttributeSubmit(cognitoUser, 'phone_number', code);

if (result === 'SUCCESS') {

  const result2 = await Auth.updateUserAttributes(cognitoUser, {

    phone_number: NEW_PHONE_NUMBER,

    'custom:validated_phone': NEW_PHONE_NUMBER,

  });

}

Now again my lambda trigger but this time both attributes are equal to each other, therefore after updating this real phone_number attribute I fail lambda intentionally so another verification code isn’t sent again

  if (validated_number === event.request.userAttributes.phone_number) {

    throw new Error('failed to prevent sending unnecessary verification code');

  }

Conclusion:

I know its tricky but much better than setting up your own verification method with DynamoDB etc… Hope it helps.

This solution has stopped working. We first noticed today but we had users report problems over the weekend. The problem seems to be that ‘verifyUserAtttributeSubmit’ now changes the attribute to the new one (in our case the new email). So by the time the second updateUserAttributes call is made, the lambda is not triggered sine the email is technically not being changed, therefore we cannot complete our full update because we had some extra logic in the final if statement.

Note: we implemented this hack for email change. Worked the same as the phone number example.

AWS cognito has been a pain point in our system. Lack of support, fixes, or improvements has been extremely frustrating. And in this case a change in underlying behavior that I have not found documented anywhere is just a cherry on top.

We need to figure out another hack to fix this original hack. I will report back with a fix as soon as we find one.

Hi, I am Amit from the Cognito team. Appreciate you all taking the time and providing valuable feedback. I wanted to let you know that we heard you and know we are continuously adjusting our roadmap balancing our customers’ operational needs against new features requests and enhancements to existing functionality. That said, we are evaluating a change to address the feedback here (Can’t comment on specific timeline). Thanks!

As developers, we all know what “evaluating” means. Effort vs ROI. As much as I want to be hopeful, after 3 years, and now it’s in evaluation.

Hey, if that’s the case (likely), I’ve been recommending auth0 whenever I have the chance after my experiences with cognito.

hello,

I solved it by following what has been said in previous posts : using cognito lambda trigger custom message and using the following option in Cognito “attributes” settings : "Email address or phone number - Users can use an email address or phone number as their “username” to sign up and sign in. " I had to create from scratch another user pool since you cannot switch from “Username” to “Email address or phone number”.

cheers

Is there an update on this issue?

Wondering if you reached out to the Cognito team and what their response was? Is it a fixable issue that the Cognito team is looking at, is it just the way it’s going to be, can you give us the summary of the status.

This is a real pain point for anyone who uses email as username and provides a change email functionality, because it’s very easy for users to get locked out of their account if they do something wrong.

@marcelloromani I think that it was just an example to show how to resolve the problem to the Cognito team, I don’t think that UpdateAfterVerification exists.

Still waiting for the fix 😦

Not Stale!

Same issue as @jiwabob.

1. Using Email address as the username for sign up and sign in.
2. Email verification is required in the user pool.
3. The user requests an Email change, but doesn’t verify the new email with the code.
4. The new email is already updated in the users attributes in the user pool, even though it wasn’t verified.
5. If the user logs out they can only log in with their new - not verified email.
6. The new not verified email is already taken in the user pool, which blocks any users who might have that email from using your website.
7. The old email the user used is now available

This would be very confusing for any user to experience.

The solution as in the quote posted from @clintfoster would be to have the email attribute updated only after it was verified.

Can we get any update on the status

For those who don’t yet have their user pool in production this comment from Cognito team member @timwhunt last fall may be helpful: https://github.com/aws-amplify/amplify-js/issues/987#issuecomment-531025897

Unfortunately we have a user pool that was created the “old way” with email aliases, rather than the new technique where the email address is literally the username. I would be curious to hear how this is working out for anyone who has tried it. I’d also love to hear any ideas for migrating an existing pool.

I dug into this a bit more and here’s what I decided to do in case it’s helpful for anyone else. My Cognito is set up so that email is considered the username.

Currently, a user can sign up for a new account which requires them to confirm their email. This sets their account status to CONFIRMED and email verified to true. However, the flaw is that afterwards the user can then change their email but then not verify that email and technically still be considered an authenticated user and sign in freely. Their account status is still CONFIRMED but email verified is false.

What if the email they changed to was inputted incorrectly? Also, for security reasons I don’t want any accounts where users haven’t verified their email since my app deals with a lot of personal data. Ideally, Cognito wouldn’t change a user’s actual email until it’s been verified.

This is what I ended up doing:

• I added an additional “confirm email” input to reduce chances of a user inputting an incorrect email.
• Assuming they verify the new email then and there, they’re logged out so that when they log back in the user’s email shown as the new one using Auth.currentAuthenticatedUser(). Otherwise, it’ll show the old email. Also, I wasn’t able to figure out based on the Auth API how to refresh the user other than signing them out and back in.
• On login, I now check a user’s email_verified attributes. If it’s set to false, I put them into an email confirmation flow similar to sign up and prevent them from logging in. Previously, even if email_verified was false Cognito would still sign you in.

It’s not 100% perfect, but working within the constraints of Cognito it solves some of the issues. Would love to hear what others think.

@clintfoster thanks for confirming I’m not crazy! Was really losing my sanity over this.

@yuntuowang what is the best way to communicate this to the backend team? I understand the security reasonings behind this, but definitely feels like a flaw in the overall design. I know it may take a while to get this fixed, but do you think it’s worth documenting here for now: https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html?

I was just contacted again by AWS recruiters, and I gave them this link as my reply exactly as I said I would.

I think it fair to say after many years of watching this issue, that Amazon has proven multiple times that the very jr. engineers that are placed in high priority roles for this critical service are simply too incompetent to design a working and functional system that is secure, because leadership simply does not care about customers.

Every single one of the now 16 amazon leadership principles is being violated by this incompetent and not at all customer focused team. Cognito is the one service that is holding the rest of AWS back, and Amazon needs to look into its Cognito Problem.

I’m getting really tired of all the lies and bs from Amazon about this.

We have waited years for a fix to a very basic thing, something that is expected of us to fully support as part of simple common standard regulatory and legal compliance; something that we just can’t skip.

Amazon’s abject failure to maintain secure systems or maintain credibility or compliance with the regulatory standards that they are now falsely claiming to be compliant with - these issues alone would make you fail any PCIDSS audit - is an absolute failure that has put an untold millions of users at risk and harmed developers efforts to use the platform.

Somebody on the Amazon leadership team who is high enough to be able to dictate a policy and fix this needs to show Leadership and do so; The Cognito team is holding Amazon Web services back as a company.

@swapnil0545 What I was trying to say is that you can only validate an email address to an extent just by looking at the string. (first question of your sentence 😃 )

But you want to replicate their validation on the FE. OK, only they can reply 😛

Do we have a regex for valid email id? What is aws cognito using at backend to validate it?

not stale!

Per the following response to my original report against the old Cognito SDK, this is a known service-side issue. If someone at AWS is reading this would it be possible to check on that issue…?

https://github.com/amazon-archives/amazon-cognito-identity-js/issues/515#issuecomment-350145613

If you follow my steps 1, 2, 3 in the original report you can reproduce the problem. It’s hard to get the gist of it just reading the descriptions.

@sChupin There’s a discussion about the email capturing behavior here (unrelated to this issue).

I’m also experiencing the issue of having blocked users when they update their email and logout before validating the new email with the verification code.

In addition to that, I’m facing another dangerous behavior with email updates. A user is able to change his email to an email that is already linked to another account without cognito returning an error. I don’t know what is the exact state of the cognito database resulting to this action but it seems that the latter account is replaced by the one “stealing” its email address. The expected behavior would be cognito returning an error such as “email already in use” when a user try to change its email address to an email address of an existing account.