Login with google for the second time : email Attribute cannot be updated

[uchar]

Describe the bug
I have the same problem as this #issue. If you make a user pool with required email field then the second google login attempt fails.
changing required fields after creating UserPool is not possible and deleting the UserPool and making a new one doesn't look like a good solution to me because by doing it I will lose all my user's data!

To Reproduce

1. Make a new UserPool with email attribute as required field
2. Enable Google federation in UserPool
3. Try to login for the second time using hosted ui
4. It should give you this error: email Attribute cannot be updated.

Expected behavior
When we use same email address it shouldn't update email attribute!

[powerful23]

@uchar Hi, did you map the email attributes from google to the Cognito User Pool? There is an section Attribute mapping under Federation in the Cognito User Pool console that you can do the mapping.

[uchar]

@uchar Hi, did you map the email attributes from google to the Cognito User Pool? There is an section Attribute mapping under Federation in the Cognito User Pool console that you can do the mapping.

Yes I did, and It works fine for the first time but trying to sign in for the second time give me that error

[powerful23]

@uchar I tried to reproduce issue but couldn't. I have the email attribute as required in my user pool setting. Is your email attributes mutable? There is a Set attribute read and write permissions secton under App clients.

[jcharlesworthuk]

I'm experiencing a similar issue, same setup as @uchar but I'm getting "Exception processing authorization code" the second time I sign in.

In answer to your question @powerful23, the email is ticked as writable under App Clients. In fact for me there is a message there that says Required attributes are always writable

[adrian-brennan]

I can reproduce the same issue. email is not mandatory for my pool, and is selected as readable and writable by my app client. First time login succeeds (and the email attribute on my Cognito user is populated), subsequent logins fail with 'user+attributes%3A+email%3A+Attribute+cannot+be+updated' error.

I worked around it by creating a custom attribute called 'emailaddress' and mapped the Google email attribute to that.

[vladistan]

Got the same problem. I am not using amplify, just regular OIDC client library.

I get this error when using Google and SAML login through ADFS. Also doesn't matter if it's one of the standard attributes or a custom one. I tried to map 'name' attribute from google to customName, and now I am getting an error message saying 'customName' could not be updated

[sammartinez]

@uchar Are you still experiencing this issue with later versions of Amplify? Please let us know

[stale]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

[AlexeyKhmelev]

Still have this issue. Terrible. User pool is already in production. Can't recreate it...

[rpstreef]

What's the resolution here because this is still happening

[pavanelthepumisc]

Any updates on this? I'm having exactly same issue.

[wadewomersley]

Happening here too.

[uchar]

It seems after two years of my report, you guys still don't fix it
@sammartinez Actually, I moved away from Cognito a long time ago and can't test it anymore. It was a horrible experience with a lot of bugs and a lack of necessary features

[wadewomersley]

I updated my CF template and set the email to mutable: true and it does work fine for me now.

[fredski02]

I also experience this issue. my email attribute is set to mutable.

[JoacoChamo]

I am also having the same problem

[kewur]

I updated my CF template and set the email to mutable: true and it does work fine for me now.

you can't actually do this for existing user pools, you'll be hit by "Existing schema attributes cannot be modified or deleted."

[jahanarun]

I also faced same issue and I have to nuke my User Pool to make the email schema as mutable.
My experience with Cognito has been poor so far.
I won't be recommending Cognito to anyone, unless AWS makes it a priority.
Azure AD experience was much better.

[uchar]

@sammartinez Hi, I think you should reopen this issue, since it's still happening and not fixed after a couple of years

[abdallahshaban557]

Hi @uchar - can you please submit a new Github issue for us following our template so that we can investigate this? https://github.com/aws-amplify/amplify-js/issues/new?assignees=&labels=&template=1.bug_report.yaml

[uchar]

@abdallahshaban557
As I said before, I don't use Cognito anymore, just saying this because this thread's notification is still popping up in my inventory.
Also not sure why you need a new issue,I think this thread's descriptions are pretty obvious and easy to follow for investigation

[nadetastic]

Hi @ershovio , Re-opening this issue

Could you share how you have mapped the attributes between google and cognito?

[a-v-ershov]

attribute_mapping=aws_cognito.AttributeMapping(
                email=aws_cognito.ProviderAttribute.GOOGLE_EMAIL, fullname=aws_cognito.ProviderAttribute.GOOGLE_NAME
            ),

[a-v-ershov]

I use AWS CDK with Python

[nadetastic]

Could you share a screen shot of how this looks like from the cognito console? @ershovio

To get there:

1. Select the user pool from the list at - https://us-east-1.console.aws.amazon.com/cognito/v2/idp/user-pools (make sure to also choose the correct region)
2. Go to "Sign-in experience" tab
3. Under "Federated identity provider sign-in" select Google
4. View and share the "Attribute mapping" section

[a-v-ershov]

[a-v-ershov]

@nadetastic any updates on it?

[nadetastic]

Hi @ershovio

I haven't been able to reproduce this issue with the same configuration you have. Since you have both email and name attributes set to Writable, you should not be having this problem - so I'm curious what else could be causing it.

Note that if you setup you resource with the Amplify CLI, or through the Cognito console, you will not face this problem, which leads me to believe that there might be something else with how the CDK is generating your resources.

I've discussed this with some folks from the Cognito team and are continuing that discussion.

One thing I recommend is to try the work around mentioned on the Amplify documentation regarding the use of existing Cognito resources. In short you will

1. Create a new public app client within your user pool
2. Make sure the required attributes are set to writable
3. Test with via a sample/copy of your application with this new app client

[a-v-ershov]

I needed to change the email and name as mutable in the CDK template - it solved the problem

[nadetastic]

@ershovio Glad you were able to get this resolved. I'll go ahead and close this issue

Thank you!

[anjanvb]

@nadetastic I have the following attributes set to write, but I still encounter this issue with OIDC authentication. I don't think this issue is fully resolved. First login seems to be fine but subsequent logins seem to be an issue. I can even see external (OIDC) user in the userPool user list. Please, reopen this.

FYI @abdallahshaban557.

const standardCognitoWriteAttributes = {       
      email: true,
      familyName: true,
      givenName: true,
      locale: true,
      phoneNumber: true
    };

User in UserPool

[abdallahshaban557]

Hi @anjanvb - can you please create a new Github issue with the details we need to troubleshoot this?

[vicodinvic1]

got the same issue

[nadetastic]

Hi @anjanvb @vicodinvic1 i have reopened this issue to look into the problems you are facing.

Can you confirm how you configured your Cognito resources?

To elaborate on the above, did you use the Amplify CLI, or AWS CDK/SDK/CloudFormation ETC

[anjanvb]

@abdallahshaban557 @nadetastic so I think the console is a bit confusing.

My userpool is being created with CDK cognito.UserPool and previously I had it setup with this

email:{
    required: true,
    mutable: false
}

But then i had this in the code

new cognito.ClientAttributes()
    .withStandardAttributes({       
      email: true,
      familyName: true,
      givenName: true,
      locale: true,
      phoneNumber: true
    });

and assigning the above to readAttributes: for the UserPool while adding the client.

This caused the console to show that the email attribute on the client app is both read and write, whereas that turned out not to be true. So I ended up deleting the entire stack and re-deploying with changing mutable to true, and it worked.

I guess the confusion stems from the fact that standard attributes within writeAttributes (documented here) and standardAttributes (documented here) are sort of treated differently, so I am not sure if this is a CDK/Cfn or a Cognito issue.

[nadetastic]

@anjanvb Thanks for the follow up and clarification, I'm glad you were able to resolve this.

I believe the confusion comes from the use of the terms "writable" and "mutable". Note that these are different and independent, in the way that "mutable" is specific to the userPool and "writable" is specific to the userPoolClient.

A scenario to help elaborate on this:

1. You have the attribute set to "immutable" on the userPool - meaning once it is set, it cannot be changed
2. Have the same attribute set to "writable" on the userPoolClient - meaning the userPoolClient can write to the userPool attribute.
3. Login the first time, and the userPoolClient writes to the userPool attribute, setting the value.
4. Login a second time, and the userPoolClient fails to write to the userPool attribute as it is "immutable" and cannot be changed.

This will result in a situation similar to what you and others have faced on this issue.

In short, be sure you are setting the attribute to both "mutable" on the userPool config and "writable" on the userPoolClient config.

References

• UserPool Mutable definition
• UserPoolClient Writable definition
• Mapping Attributes To Identity Provider

[anjanvb]

@nadetastic thanks for the clarification, makes sense. Given that it is known situation, i think a clarification of writable vs mutable in Amplify docs will be super helpful. I guess the other aspect of it is debug assist, for example it could be misleading a bit, especially since the userPool level attributes are not immediately obvious to the user from looking at the console. The user only sees the attributes at the userPoolClient level from the console, perhaps not the userPool level.

For example take a look at this userPoolClient attribute list, you can see that custom:userRole is marked as (mutable) but email isn't even though it really is as I explained previously. Technically email should also have the (mutable) marker along with Write marker since it's both writable and mutable.

[nadetastic]

@anjanvb I have updated the docs and included a callout that mentions the difference between mutable and writable attributes. I'll mark this issue as closed but let me know if you have any questions, thank you!

[silentlight]

Hi everyone. So in order to federated login to work I need to have email set to mutable for my user pool? I currently have user pool where email is immutable and login with Google fails on second attempt.

[danielmouras]

This issue really isn't difficult to understand. The correct behavior should be that when someone tries to log in again with Google or Apple, the system shouldn't attempt to overwrite the existing email, especially not when we're just dealing with a sign-in function. This would be a much simpler solution. Yet here I am, five years later, still facing the same problem.

It's absurd that this task has been closed so many times, especially when, five years later, using version v6 with a different method (signInWithRedirect), I'm still experiencing the same issue. It seems like all the recent Amazon layoffs were from the Amplify team, because there's absolutely no support.

[JViggiani]

It is unbelievable that this gets closed again and again. Reconsidering Cognito because of this. Might go with okta, auth0 or, god forbid, azure

[proper-gentleman]

So what is the status on this? It seems it's still happening.

http://localhost:3000/#error_description=user.email%3A+Attribute+cannot+be+updated.%0A+&state=PBhQV3LDT4Y2UaKWV4Tveh9poOxcRopX&error=invalid_request

[anasnadeemws]

any update on this?

It's still happening
http://localhost:3000/#error_description=user.email%3A+Attribute+cannot+be+updated.%0A+&state=sBsteJz6rlkxGXuFFzu3VdBsCGui4hJk&error=invalid_request

[gambin]

Perhaps this is not the best thread to report it, but I was facing the same nightmare in a TerraForm implementation. Solved that turning some implementations explicit, such as:

resource "aws_cognito_user_pool" "user_pool" {
  name = var.user_pool_name
  auto_verified_attributes = ["email"]
  alias_attributes         = ["preferred_username"]

  schema {
    name = "email"
    attribute_data_type = "String"
    required = true
    mutable = true
  }

  schema {
    name = "preferred_username"
    attribute_data_type = "String"
    required = true
    mutable = false
  }
}

resource "aws_cognito_user_pool_client" "user_pool_client" {
  user_pool_id = aws_cognito_user_pool.user_pool.id
  name = var.client_name

  read_attributes = ["preferred_username","sub","email"]

More details:
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cognito_user_pool
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cognito_user_pool_client#write_attributes-1