How do you want users to be able to sign in when using your Cognito User Pool? Username + email + phone

[oste]

Is your feature request related to a problem? Please describe.
When doing amplify add auth and getting to the question " How do you want users to be able to sign in when using your Cognito User Pool?" there is an option to choose Username but it is not possible to also allow users to sign up with email and phone. It should be possible to enable these options since they are in the "attributes" section of the cognito UI.

Describe the solution you'd like
Add ability to check these boxes when running amplify add auth
Also allow sign in with verified email address
Also allow sign in with verified phone number
Also allow sign in with preferred username (a username that your users can change)

Describe alternatives you've considered
Would probably have to create the user pool first and then add it that way.

[haverchuck]

This is not currently supported in CLI, but can be implemented without major refactoring or new features. Marking this as an enhancement request. Thanks for submitting.

[babus]

@haverchuck This is a major bump. It should have been available as mandatory as these settings cannot be modified after creating the pool. Why I'm tagging this as major is that we have the issue #779 using the existing pools created using console. So either way, we cannot create or use a pool with the above settings which is a straight shot contradiction to the purpose of amplify framework.

[babus]

For now I had patched the .yml and .json files to achieve what I want. Had to go through a trail and error process. So attention needed while updating the templates.

*-parameters.json changes

"aliasAttributes": ["email", "phone_number", "preferred_username"],
"mfaConfiguration": "OFF",
"mfaTypes": [],

Remove "autoVerifiedAttributes" parameter from parameters.json.

*-template.yml changes

• Replace "AutoVerifiedAttributes:" with "AliasAttributes"
• Replace "AutoVerifiedAttributes: !Ref autoVerifiedAttributes" with "AliasAttributes: !Ref aliasAttributes"

I added pre-signup lambda to auto confirm the user before signup. And added a post-confirmation lambda to set the preferred_username to cognito:username. With this setup, from the hosted UI, the user can signup with cognito:username and password. By then, the preferred_username will be set with cognito:username and we can use preferred_username hereafter as the username for the user by never exposing the cognito:username. I hope that if the user is adding an email or phone number and verified in future, they should be able to signin with them.

Pre-Signup lambda

exports.handler = (event, context, callback) => {
  event.response.autoConfirmUser = true;
  callback(null, event);
};

Post-Confirmation lambda

exports.handler = (event, context, callback) => {
  event.request.userAttributes.preferred_username = event.request.userAttributes.username
  callback(null, event);
};

The only thumbs down is that when we amplify update auth the json and yml files are getting overridden. Though the code we added into these files are remain intact, it keeps adding the code we removed. Also I commit the code to source control so that I can identify diff easily and undo what ever has been re-added.

Also while creating pool, I chose Username and left all the fields as not required importantly the email, phone_number and preferred_username. Some how if we set the preferred_username as required this method won't work. Confirmed the same from the AWS support.

[springcoil]

Does this work as a solution? @babu-upcomer

[michelem09]

@babu-upcomer workaround works but you need also:

*-template.yml changes
Add

  aliasAttributes:
    Type: CommaDelimitedList

Remove

  autoVerifiedAttributes:
    Type: CommaDelimitedList

*-parameters.json changes
Add
"aliasAttributes": ["email", "phone_number", "preferred_username"],

[babus]

@michelem09 yeah! my choice of words :( @springcoil Yes this works as a complete solution.

[dmdmd]

@babu-upcomer or @michelem09 do you mind posting your parameters.json file? I'm still having trouble implementing your solution and I think it's due to some of the settings I'm selecting.

[legiaquangvn]

I tried, it didn't work.

Following resources failed
...
Reason: Updates are not allowed for property - AliasAttributes. (Service: AWSCognitoIdentityProvider; Status Code: 400; Error Code: InvalidParameterException; Request ID: null)

[martaGonz]

@babu-upcomer when I change the template and parameters I get this error, do you know why?

Updates are not allowed for property - AliasAttributes. (Service: AWSCognitoIdentityProvider; Status Code: 400; Error Code: InvalidParameterException; Request ID: null)

[multidis]

@martaGonz this happens because AWS Cognito does not allow modifying user attribute settings after the pool was already created. You probably need to create a new amplify backend, go over the amplify add auth prompts, then modify the CloudFormation template, and only afterwards run amplify push.

[martaGonz]

@multidis thank you so much. It's working now!

[claym]

Did this ever make it into the CLI or is manual intervention still required?

[bobbles911]

amplify is just not usable for me. All non changeable attributes should be able to be specified on the cli

[NodeKing]

Ok, so I've spent a day on this editing config files and finally got it working, then discovered that usernames are case sensitive (Why on earth would anyone want case sensitive usernames). There is no documented way to implement case insensitive usernames in amplify that I can find.

I thought amplify was created to make development quicker. I'm really surprised that the cli doesn't present you with all the same cognito options as the admin portal.

I'm a long time AWS user, and the frustration has me seriously considering alternatives.

I'm shocked that this has been an issue for so long and hasn't been addressed.

The solution is to create everything manually I guess and link it all up. Kinda defeats the purpose of the framework.

[wvidana]

@babu-upcomer It looks like the workaround in #1546 (comment) worked for the User Pool creation, but any updates will replace back the aliasAttributes with autoVerifiedAttributes, which results in the following error from Cloudformation

Updates are not allowed for property - AliasAttributes. (Service: AWSCognitoIdentityProvider; Status Code: 400; Error Code: InvalidParameterException; Request ID: null; Proxy: null)

Any response from AWS devs?

[babus]

@babu-upcomer It looks like the workaround in #1546 (comment) worked for the User Pool creation, but any updates will replace back the aliasAttributes with autoVerifiedAttributes, which results in the following error from Cloudformation

Updates are not allowed for property - AliasAttributes. (Service: AWSCognitoIdentityProvider; Status Code: 400; Error Code: InvalidParameterException; Request ID: null; Proxy: null)

Any response from AWS devs?

Moved away from amplify a long back. It is less customizable and I wouldn't wonder if this is still an issue.

[gbumgard]

Moved away from amplify a long back. It is less customizable and I wouldn't wonder if this is still an issue.

Yes it is. :b Been fighting my way through Amplify for weeks now. I can't imagine adding the ability to specify the login options in the cli would be that difficult. I have found myself editing the amplify-generated stacks for all sorts of reasons and it is a total PITA to find that some changes are overwritten on update. The most common changes I have to make mostly involve IAM roles and permissions - I've found you can't add policies through the IAM console as it will cause cloudformation failure whenever an amplify IAM resource is deleted by an amplify stack - you have to modify the stacks to do it correctly. I suppose I could add my own custom auth/cognito resource to the project to get what I want (as I have for creating an RDS/Aurora cluster), but that adds yet more complexity and maintenance issues. I have found myself stuck in a cycle of regenerating the same app over and over again after finding myself stuck down some blind alley and am forced by backtrack on the resource definitions and am unable to do so after deployment due to cloudformation stack conflicts. The framework is very close to providing what I need, but not quite there yet.

[kaustavghosh06]

@gbumgard Could you please talk about the use-case as to the reasons you're modifying the IAM roles and which specific CloudFormation resources that you're modifying for auth?

[gbumgard]

@gbumgard Could you please talk about the use-case as to the reasons you're modifying the IAM roles and which specific CloudFormation resources that you're modifying for auth?

I'm sure I'm forgetting something, but definitely added lambda invoke to the pre-signup and post-confirmation triggers as I use a third lambda function to break the Cognito/API circular dependency loop so I can shadow the user attribute info in Cognito in a database table accessed via the AppSync API (to provide subscription support). I cannot explicitly create a dependency between those lambda functions to generate the lambda-invoke policy as that will again introduce a circular dependency with Cognito. IIRC, I also had to add an AppSync access policy to the role assigned to third lambda manually to again avoid a circular dependency in the stack parameters. Frankly, it's all very confusing.

I'm currently refactoring the lambdas now, so will have an opportunity to revisit how I make these policy changes to the stack or why I used the IAM console. I pretty much broke everything last night by deleting a type and associated lambda function bindings in my schema and I really could not determine why - the push operation appeared to fail when one of the stacks attempted to delete a role for some reason and the rollback left the resources in some indeterminate state. At that point, I found myself completely stuck - the actual state in the deployed backend no longer matched the current cloud backend state maintained on my machine and nothing I could do would fix it. I tried my usual solution of creating a new environment to regenerate the backend, but this also failed. I'm sorry, but I did not log the process and errors that I encountered. I finally gave up and manually deleted all of the stacks and resources as I could no longer do it via the Amplify CLI and am currently going through the entire app generation process again - this time trying to create my own custom resource for Cognito auth (basically just copying the amplify generate stack with modifications). It's not all that difficult to do - just time consuming.

FWIW, one last note - if the Amplify CLI 'add auth' is used to add trigger lambdas during setup, a 'remove auth' does not remove those trigger functions even though they are treated as a dependency by the auth resource. Not sure whether that would prove to be a problem, but it does seem like something one would expect to happen, or at least be queried for.

-g.b.

[mikelhamer]

Is there still no word on if this will be addressed?

[gbumgard]

Is there still no word on if this will be addressed?

I edited the CF template to add alias support. Here's how I did it:
https://gbumgardner.medium.com/create-a-cognito-user-pool-with-sign-in-aliases-using-the-amplify-cli-c432049cc199

[alionthego]

Has anybody tried creating the User Pool in console with the required settings and then in the cli entering: 'amplify import auth'? Not sure it will work or how updates will be handled but sounds promising.
https://docs.amplify.aws/cli/auth/import

[MiraiTunga]

@alionthego this worked for me, but not sure how updates will work in future

[github-actions]

👋 Hi, this issue was referenced in the v5.2.0 release!

Check out the release notes here https://github.com/aws-amplify/amplify-cli/releases/tag/v5.2.0.

[THPubs]

@johnpc Thanks for implementing this feature! But is it possible to add alternative sign options to an existing project? I just tried to update auth and it did not give me this option.

[github-actions]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.