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

[danielgeri]

Do you want to request a feature or report a bug?
reporting a bug

What is the current behavior?
Our cognito pools are set up so that users can log in with their email. We also utilize attribute verification so that once a user signs up, they will need to verify their email address. Where we get stuck is when a user needs to update their email address. We call updateAttributes and pass their email, which will then send the user a verification email with the confirmation code. There are however states where the user is unauthenticated and needs to verify email with the confirmation code. If they are in an unauthenticated state, they need to authenticate. However, cognito doesn't allow users to log back in with neither their old or new email address. Instead, they need to sign up for an account again. This is a huge issue for us since it leaves users in this limbo state.

What is the expected behavior?
The expected behavior would be for users to log in with the email address that has been verified in prior to attempting to change the email, which would then allow the user to verify the new email address.

Which versions of Amplify, and which browser / OS are affected by this issue? Did this work in previous versions?
This has never worked

[clintfoster]

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.

[danielgeri]

@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?

[sloansparger]

@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.

[danielgeri]

@sloansparger sorry to hear :( Your scenario seems super odd since that is a major security flaw. Regardless of the mechanics of the issue I would recommend the following:

1. handle email verification outside of cognito
2. use preferred username, etc as the email address that you can update and login with when email is verified (untested fyi - just a theory)
3. switch to an auth provider that is more proven? e.g. auth0

[sloansparger]

@danielgeri Interesting idea, I'm going to look into option 2 until we hear some feedback from the Cognito team. Thanks 👍

[danielgeri]

@sloansparger np! if you end up implementing, can you let us know how it goes? I am super curious to see if it's a viable workaround

[sloansparger]

@danielgeri Unfortunately this doesn't seem to work as I'm getting this error: { code: "InvalidParameterException", name: "InvalidParameterException", message: "Invalid email address format." }.

After a little digging, this page in the docs seem to explain why:

If email is selected as an alias, a username cannot match a valid email format. Similarly, if phone number is selected as an alias, a username that matches a valid phone number pattern is not accepted by the service for that user pool.

[huihe]

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.

[daneprime8]

Also experiencing this issue. Cognito, please advise.

[pixelier]

Experiencing the same issue. Is there any solution for this case?

[sloansparger]

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.

[lazharichir]

Is there any update on that issue?

[jordanranz]

Has anyone opened up this issue with the Cognito service center support?

[danielgeri]

@daneprime8 @lazharichir We ended up building our own email verification process.

@jordanranz I have not. I've had other core cognito issues (not related to aws amplify) and don't know where to go to reach out to the core cognito team. Mind advising on how to approach this (i.e. where is the cognito service support center)?

[jordanranz]

@danielgeri I think you'd start on the Cognito forum page.

or submit a claim by opening a case in the AWS Support Center

[j0b0sapi3n]

Also experiencing this, please respond Cognito.

[j0b0sapi3n]

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.

[Susan123456789]

Any news? I am experiencing the same problem. Users can change their email address without confirming it, and then log in using the new email address without it ever having been verified.

[cameronb23]

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.

[clintfoster]

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.

[duaneking]

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.

[hkjpotato]

@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.

[duaneking]

@hkjpotato That's appreciated. The biggest frustration I have is that no matter how many people I managed to get on the phone after paying for the support I ended up never actually getting, nobody from the Cognito team could ever be contacted or forced to get on a call with me as a paying customer. They refuse to interact or communicate with customers, and actively use others on various support teams that support them as cats paws/scapegoat's/fall guys/etc, throwing every other team they interact with under the bus for issues they created by their incompetency and lack of customer focus.

[AWSAmitjh]

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!

[stubbzilla8]

I'm excited about a potential resolution here!

[Mateozmaldonado17]

Omg, 3 years and nothing!!!

[pomSense]

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.

[DanyPell]

Looking forward to fixes related to Cognito / Amplify.

[stubbzilla8]

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.

[grodriguez85]

It's disappointing this issue is still unresolved; nonetheless, I'm more intrigued about how is the recommended way on Cognito to prevent an unauthorized change in email while AFK? The email verification restriction before signing in again after an email change is great, but why Cognito doesn't enforce giving the current user's password to allow the change in the first place?

[PhilippS93]

We also encountered this issue in our company, very disappointing..

[duaneking]

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.

[hitesh-getzenda]

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

[duaneking]

@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.

[tanuj-g]

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.

[ericperriard]

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.

This 2-steps solution is the one I've chosen as well. It's a clean approach, thanks for sharing!

The only thing I've added is to avoid sending the new email address from the front end in step 2 (verification phase). It's a security issue. At this stage, the user has a token, a valid code... and could potentially ship any other unverified email to be saved in Cognito as "verfified".

So in phase 1 (requesting an email change), I've stored the new email in the Cognito field "preferred_username", so I could retrieve it for phase 2. It's an easy fix, and requires very little code change from the suggested solution.

[ninjarogue]

hey this is ridiculous, when is this going to be fixed?

[duaneking]

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.

[duaneking]

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.

[fernandoaguilar]

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.

[pyroflies]

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.

It's beyond ridiculous how garbage the support is for cognito. Lack of documentation, no response on critical issues and features such as this, forcing developers to come up with workarounds, then the audacity to randomly, SECRETLY pushing behavior changes to prod, BREAKING live clients with no announcements, no nothing.. just wow. This cognito team, product, what a complete joke. 🤡

[duaneking]

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 was just contacted again by AWS recruiters, and I gave them this link as my reply exactly as I said I would.

[duaneking]

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

[DanyPell]

I hope they do something about it and improve Cognito.

[undefobj]

Hello everyone. We've worked with the Amazon Cognito team on this issue and they have taken the feedback to address the request for changes in the service.

The service changes have been released and are available today in Cognito via the Console or CloudFormation. We will be incorporating these changes into the Amplify CLI and Studio in upcoming releases. Please see the information below for configuring the new functionality in Cognito:

A new section titled Verifying attribute changes has been added to the Amazon Cognito console. With the feature active, you can choose to keep the original value of an email address or phone number attribute value active when an update is pending. With the feature inactive, Amazon Cognito continues to follow legacy behavior when a user changes their email address or phone number: they can’t sign in or receive messages with the original or new value, until they verify the new value.

You can configure the feature to apply to email address, phone number, or both.

When you turn on this feature for a user with a pending attribute change, that user will continue to receive messages and sign in with the original attribute value until they verify they new one. After they enter a code or follow a link to verify their new information, they can receive messages and sign in only with the new attribute value. Your users will benefit from this new feature because your users won’t lose access to your app when they have a new, unverified email address or phone number.

You can change user attributes in the Amazon Cognito console or with the API operations UpdateUserAttributes and AdminUpdateUserAttributes. When you configure your user pool to retain the original attribute value pending verification, your user’s original attribute value remains active until you make a VerifyUserAttribute request.
Amazon Cognito has introduced the new settings group UserAttributeUpdateSettings, and the new parameter RequireAttributesVerifiedBeforeUpdate. To activate this feature with the Amazon Cognito API, set the value of RequireAttributesVerifiedBeforeUpdate in a CreateUserPool or UpdateUserPool API request.
For more information about these API operations and fields, see the Amazon Cognito API reference (https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/Welcome.html).