Cognito Custom Auth Flow - Passwordless but restricted at email domain! Is it possible?

0

Hello - I managed to get the Cognito passwordless CUSTOM_AUTH flow working - however it seems for this to work users need to either have signed up to the user pool or exist in the user pool prior to calling initiateAuth.

My requirement is to be able to give out tokens to users that aren't in the user pool but are part of a given email domain. The current passwordless flow works such that:

  1. InitiateAuth is called with a user email this triggers the define auth and create auth lambda triggers
  2. An email with a one-time-passcode gets sent out to the user
  3. The user enters the one time passcode from their email and this is verified by the Verify Auth Lambda trigger.

Thus there is one custom challenge - which expects one answer to this challenge and based on that tokens are either issued or authentication fails.

However this only works if the user already exists in the user pool. I'm wondering if it's possible to use say a dummy email - dummy@gmail.com that is in the user pool - but then have two custom challenges. So on the Frontend form there will be a field for the user to enter their email - this will be stored and used as the response to the first custom_challenge.

The initiateAuth under the hood still gets called with this dummy email to allow us to get into the CUSTOM_AUTH flow.

Once this happens the actual email the user entered will be given as the response to the first challenge this is where a check is carried out to see if the email ends in a given domain e.g. '@example.com' if it does then a second challenge is sent to the user where the email gets sent out to them and they have to enter the one time passcode. The OTP they enter will be the response to the second custom_challenge if both succeed then tokens get issued out.

Please let me know if you think there is a better way to do this - and if this even is a viable approach - as I'm really struggling with this.

The other approaches I thought about are:

  • Run the pre-authentication lambda function and add them to the user pool if they are in that list of domains? (but what happens if they enter the wrong email?)
  • Somehow pass in their actual email as a parameter when calling the InitiateAuth function with the dummy email - but I couldn't find anywhere I could put this, clientMetaData isn't available in the Lambda Challenge Trigger
  • From the Frontend store the user email value in DynamoDB then get the value back from the lambda code and run the check before sending out the email?
2 Answers
0
Accepted Answer

Can the first challenge be something handled by another Backend API built by your own? - eg. a separate lambda function? Inside that lambda function, you can call AWS APIs if desired, you can check email domains if you want.

For example, I had a passwordless login (magic email link login) portal. The first API call is sending to my own rest api endpoint - 'https://myapi.domain.com/checkuser' with the email address entered. If the user does not exist in current userpool (adminGetUser), then create a new user (adminCreateUser). Once the first API responses back to frontend, frontend triggers custom_auth_flow of initiateAuth with the email entered.

AWS
Yungang
answered 14 days ago
  • Thank you for your answer! This makes a lot of sense as a work around - creating the user at the point of login. My only question is how do you ensure that the email entered by the user is correct and they haven't made a spelling mistake - because then wouldn't the user pool end up being filled with incorrect accounts, which I guess isn't the biggest issue but still just wondering if there is a way to prevent that. But anyway I have gone with the same work around as you!

0

It won't be able to avoid user input fake email address, unless in the checkuser lambda has a list to do correct filter before adminCreateUser.

Userpool does not too care about user amount, it's charged for monthly active user. If a user created by never signed-in successfully, it would not be counted for charge.

adminCreateUser would create a user in FORCE_CHANGE_PASSWORD state. It might be possible to execute a regular user clean up by checking whether the user ever successfully login after creation.

AWS
Yungang
answered 12 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions