Amplify CLI authentication with Cognito user pools currently has two main modes, signin with username or with email. In the former case email uniqueness as a required user attribute is not being enforced.
Cognito service by itself supports the "Also allow sign in with verified email address" option (AWS Console, User Pool Attributes-section) but it can be set only upon user pool creation (i.e. can not be modified later - checkboxes are disabled). Is it possible to enforce no duplicate emails within the user pool while allowing users to authenticate with username or with email?
To summarize, my use case requires:
Verifying/enforcing email attribute uniqueness at the Cognito level when signing up users via Amplify's Auth.SignUp;
Keeping username-based login but allowing users to login with their email as well (that is, Auth.SignIn with email or username supplied as the username-argument).
When you add the user pool with amplify add auth choose 'Username' as the method with which you want users to sign in when prompted.
If you aren't prompted with this choice, you might need to try amplify add auth again but this time choose Manual configuration when prompted at the beginning.
Once you've completed the entire auth set up via amplify add auth, BEFORE you run amplify push for the first time, run amplify override auth.
This creates a new override.ts file which you can edit with AWS CDK code to customise your Cognito resources beyond the abilities the CLI allows.
You can find the override.ts file at:
amplify\backend\auth\<your_app_name>\override.ts
Inside the override file, add the following line into the empty function that's made for you:
resources.userPool.aliasAttributes = ['email'];
Now you can save the file, and run amplify push and hopefully your new user pool will show in the AWS Console that you've successfully configured it to allow user name and email sign in together.
You have to make sure you write the override code before amplify push or your user pool will be created in the cloud, and attempting to override this sign in functionality after the user pool has been created throws an error as it's read only.
If you find yourself in that position, you'll need to create a new user pool, you can't modify the existing one.
Related
The AWS documentation for JS SDK says:
Force Change Password
The user account is confirmed and the user can sign in using a temporary password, but on first sign-in, the user must change his or her password to a new value before doing anything else.
User accounts that are created by an administrator or developer start in this state.
But if for such a user I try to call forgotPassword method of SDK, it errors saying something like: Password cannot be reset in the current state.
SO how can I complete the registration of a user (created by admin in IAM) from my website. Which is the SDK method that should be called ?
Setting up an Auto Verify Lambda Trigger on the Pre Sign Up Trigger will allow for the user to be a confirmed state, which may get you to the point you are looking for?
Lambda -> Node.js
Give it an appropriate Title
Place the below value in the code:
exports.handler = (event, context, callback) => {
// Confirm the user
event.response.autoConfirmUser = true;
// Set the email as verified if it is in the request
if (event.request.userAttributes.hasOwnProperty("email")) {
event.response.autoVerifyEmail = true;
}
// Return to Amazon Cognito
callback(null, event);
};
Save
Then Select newly created trigger in General Settings -> Triggers -> Pre sign-up
We can do this,
I previously answered mongodb to aws cogniton migration question.
Go through step by step. I explained that the user's created by admin need to change the password(forgot password) but there's still another way to do it. Checkout my answer,
Some content from my answer,
AdminCreateUser:
Create a new user profile by using the AWS Management Console or by calling the AdminCreateUser API. Specify the temporary password or allow Amazon Cognito to automatically generate one.
Specify whether provided email addresses and phone numbers are marked as verified for new users. Specify custom SMS and email invitation messages for new users via the AWS Management Console.
Specify whether invitation messages are sent via SMS, email, or both.
After successful user creation,
authenticate user using same user credentials Use: SDK calls InitiateAuth(Username, USER_SRP_AUTH)
After success of initateAuth, amazon Cognito returns the PASSWORD_VERIFIER challenge with Salt & Secret block.
Use RespondToAuthChallenge(Username, , PASSWORD_VERIFIER)
Amazon Cognito returns the NEW_PASSWORD_REQUIRED challenge along with the current and required attributes.
The user is prompted and enters a new password and any missing values for required attributes.
Call RespondToAuthChallenge(Username, , ).
After successful password change user can be able to login using same credentials which admin created.
Refer: Unable to confirm the user registration via aws
I want to make a simple flow for registration app.
User sign up with only email -> The verification/registration link is sent to the email -> People register (putting in their password) on that link
I've googled anything but haven't found any way to make it with AWS Cognito.
Looks like Cognito is forcing users to sign up with at least email AND password to get the confirmation link
You can sign up users with adminCreateUser API call. They will receive an email with temporary passwords. This approach is configurable.
See: https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html
Use: AdminCreateUser
Create a new user profile by using the AWS Management Console or by calling the AdminCreateUser API. Specify the temporary password(will be your user's password) or allow Amazon Cognito to automatically generate one.
Specify whether provided email addresses and phone numbers are marked as verified for new users.
Specify custom SMS and email invitation messages for new users via the AWS Management Console.
Specify whether invitation messages are sent via SMS, email, or both.
After successful user creation,
1. authenticate user using same user credentials
Use: SDK calls InitiateAuth(Username, USER_SRP_AUTH)
2. After success of initateAuth, amazon Cognito returns the PASSWORD_VERIFIER challenge with Salt & Secret block.
3. Use RespondToAuthChallenge(Username, <SRP variables>, PASSWORD_VERIFIER
4. Amazon Cognito returns the NEW_PASSWORD_REQUIRED challenge along with the current and required attributes.
5. The user is prompted and enters a new password and any missing values for required attributes.
6. Call RespondToAuthChallenge(Username, <New password>, <User attributes>).
7. After successful password change user can be able to login using same credentials added by you.
Short answer
- In that case, you can specify the temporary password(will allow Amazon Cognito to automatically generate one.).
- all user users will be forced to change their password only at first login.
I am trying to use AWS Cognito for my app.
I can register the users successfully to AWS Cognito, but I want to be able to also store them in my database (with my own API), too, as part of the sign-up process.
I saw that I could use a trigger function like Post confirmation, but as far as I understand, if saving the user to my database fails, then the user will still be created in the Cognito user pool.
I want to treat the sign-up process in a transactional way, so that if saving the user in my database fails, then the entire process fails.
So, it would look something like this:
Aws Cognito Sign Up -> Send_to_database_trigger ----fails----> user is not created
\---success--> user is created
Is there any way to achieve what I want? Thanks.
You can use the Pre Sign-up Lambda Trigger.
It gets the username and all the user attributes in the event and if it fails the user won't be signed up in Cognito.
In your case, you will save your user to your database in this trigger (after other possible validations) and will fail if saving to your database has failed. This way you can be sure that if a user exists in Cognito it also exists in your database.
If you need to save the sub then you can implement both Pre Sign-up and Post Confirmation and update your database record with the sub in the Post Confirmation trigger.
Cognito has a migration lambda that allows us to confirm a user in our db. They send the email and PW to Cognito, the lambda fires, we verify matches, and the user is entered into Cognito.
At this point - behind the scenes - Cognito generates a username of some kind (UUID). The problem is, I need a way to get this username into our existing database, because our systems going forward will no longer rely on email and instead rely on this username.
Ideal flow:
Sign In
Migration Succeeds
Cognito generates username
Username is sent to our server.
Now because we have email set to auto-verified, no post-confirmation lambda can be called. The only way I see to do this with Cognito as-is is to either:
Ask users who already exist in our system to confirm their email again. This is a non-starter
Create a post-auth lambda, check user login count through a custom attribute, and if 0 (or if not already registered with the service, etc.) migrate the username to the new service.
If there is any other way to do this, please let me know.
After the user migration lambda is called your pre sign-up lambda will be called, assuming you have implemented it. The parameters received by your lambda will include username with the value being the UID you referenced. Parameters will also include user attributes containing email. You can use this information to update your database.
I did not want to add the PreSignup trigger, its a complicated way of doing it if you already rely on PostConfirmation, and if the majority of new users won't be migrations. My use case has a frontend initiate the signup process as well, which I use here.
Instead, I set a Cognito attribute on the new user during the UserMigration trigger. It could be 'user_migration': <oldUserSub>, or however you want to mark it. Just make sure you allow this property within the Cognito user pool settings.
When the UserMigration trigger returns, this information is now accessible through verifying the IdToken, or found in the JWT on the frontend if you're using that. So, when the user is migrated into Cognito and the response gets back to the Cognito client on the frontend, I can now recognize this user needs to be migrated into my personal database. Seeing this, I'll call a new endpoint on my backend to handle this. This new endpoint does exactly what PostConfirmation would typically do.
Then just delete the 'user_migration' property from the Cognito user, return the new user data to the frontend and everything should be set up.
You can use Pre sign-up trigger. In order to detect if the trigger event came from your migration trigger, you can check at the trigger_source value from the event object. In my case (i'm using migration trigger) the value is PreSignUp_AdminCreateUser. By knowing the value of trigger_source you can differentiate if it was migrated or regular user. You can also check the user attributes to know whether the email or phone is verified or not.
Here's my sample code on python:
def lambda_handler(event, context):
trigger_source = event.get('triggerSource')
user_attributes = request.get('userAttributes')
email_verified = user_attributes.get('email_verified')
if trigger_source == 'PreSignUp_AdminCreateUser' and email_verified == 'true':
# create user on db
I'm developing a custom passwordless auth to sign into a Cognito user pool. I will describe what I'm trying to implement in case anything is silly. I want a user to enter their email address, then receive a magic login link via email, and when they click on that be taken back to the site and be logged in.
This uses custom auth lambda functions to define/create a challenge with a time based password and send it to the user in an email. I am having a couple of problems:
Problem 1)
When the user returns with the code they might not be in the same browser/device and certainly won't be in the same tab so they don't have the session, meaning I need to call cognitoUser.initiateAuth again. This goes through the define/create challenge lambdas again so a second email gets sent even though at this point the user is coming from the email link so already has the code. Note: the session id is not available in the event object when the challenge is created, also I've read these sessions only last 3 minutes and my time based passwords will last ~15minutes, so I don't think I can include the session id in the email.
Problem 2)
You can login from a few places (browser, android app, etc) and I would like to be able to include the url or at least protocol as a parameter to control what gets sent in the email, e.g. if you entered your email address in the android app then the email you get would be myapp://login?code=xxx and if you did it on the web it would be https://example.com/login?code=xxx
It seems like I would be able to implement both of these to work properly if only I could find some way to send custom metadata through to the DefineChallenge and CreateChallenge lambda such that it would appear in the event object. I thought adding ValidationData to the AuthenticationDetails object would do this, but that information doesn't appear in the event object in the Lambda fns.
The workaround I've found is to create a new client id for every situation - one for initiating auth, one for redeeming token, and repeat for each different protocol. But that is a lot of client ids quickly - a pain to mantain and clumsy.
So tl;dr is: I want to send custom metadata from my cognitoUser.initiateAuth(...) call in JS and have it available in my Define/Create Challenge lambda fns.
You can split the authentication process into multiple custom auth challenges. This allows custom auth state to be supplied via the challenge response as client metadata.
Auth session state must be persisted in a database in order to be shared between devices.
Your custom login flow will probably have two challenge steps: the first prompts for auth type and the second prompts for the secret code. The action taken by the "Create Auth Challenge" Lambda will depend on the auth type. If the auth type is "Email" then the secret code and magic link are generated, stored in DynamoDB and emailed. If the auth type is "MagicLink" then the secret is loaded from DynamoDB. Clicking on a Magic link will initiate a new auth session and automatically supply all the challenge answers.
There are a few other things to consider:
Your magic link needs to encapsulate the Cognito username as well as the one-time secret and probably some other session id that is used as a key in dynamodb.
You probably should not put app-specific links into your emails. Instead associate your domain with your app and/or leverage the redirect URI parameter of your web-based login page.
You can also access custom Cognito user attributes from the Lambda function which can be used to indicate user login preferences (eg Email vs SMS for login codes).