How to add passwordless-sms-auth?

[marcschroeter]

We would like to extend the solution to uses SMS as alternative way for a passwordless email auth using cognito. The goal is that the user can choose either email or sms for getting the secret code. How can we tell the lambda that the request from cognito was made by email or sms?

[ottokruse]

Interesting question! No really easy way to do this I'm afraid, as you can't pass instructions along in the signIn call that could be accessed by the createAuthChallenge trigger. Thoughts that come to mind to someway get there:

• save the choice (email or SMS) in a DynamoDB table and read it from the createAuthChallenge trigger to know what to do.
• provide the choice (email or SMS) as validation meta data in the signIn call. Then use a PreAuthentication Lambda trigger (that has access to the meta data) to write the choice to the user's attributes in Cognito and read from there in the createAuthChallenge trigger to know what to do. edit: this seems to not work, as pre-auth lambda isn't triggered in custom auth flow

Interested to hear what route you guys end up taking.

[ottokruse]

Was this resolved? Can the issue be closed?

[mmeylan]

Hi @ottokruse. We're also looking to add that exact use case. We want to give the choice to our users to get their auth code by sms or email.

• We've played with cognito sign-in aliases (email & phone number), but it seems that it's one or the other
• We've played with PreAuthTrigger. We wanted to update a custom attribute based on ClientMetadata passed in from Auth.signIn, but as you've said it's not called for custom auth. Btw, is that a known bug at AWS ?

We're not sure yet how we'll solve this. Updating a DynamoDB table seems overkill for something like that. It seems very unnatural to have no way to transmit some meta data from the client to our custom auth flow triggers. Any more insights since your last message ? @marcschroeter Have you solved it ?

It seems many people want to do similar use cases.(aws-amplify/amplify-js#5318)

[ottokruse]

Is it always either email or sms? Then you could make a user attribute out if it in Cognito, that you store while registering the user. User attributes are available in the custom auth lambda's.

What company do you work for? I can add you to the internal feature request to Cognito team, that does help. Send me a DM on Twitter if you want: @ottokruse

[jhecking]

@ottokruse Any update on this?

We have a very similar problem. We would like to send the auth code via SMS at first. But some users are unable to receive SMS, so we want to offer them a fallback via Email instead.

[ottokruse]

Here is a solution that allows the user to choose SMS or email. It does not use DynamoDB but rather a more sophisticated custom auth flow:

https://github.com/ottokruse/amazon-cognito-passwordless-email-auth/tree/email-or-sms

It's rough but it works. We'll make it more proper and include docs at some point, but for now you can check out the code to see a way to do it. You can deploy it in the exact same manner as the repo here.

The trick the solution uses is to add an additional challenge in the custom auth flow, "CHOOSE_EMAIL_OR_SMS", that will allow to client to respond with clientMetadata with the choice "email" or "sms". Interestingly, if you include clientMetadatain the RespondToAuthChallenge call this clientMetadata is visible in the custom auth lambda's, and therefore you can get it all to work.

Note, the Cognito custom auth docs do mention:

clientMetadata
One or more key-value pairs that you can provide as custom input to the Lambda function that you specify for the define auth challenge trigger. You can pass this data to your Lambda function by using the ClientMetadata parameter in the AdminRespondToAuthChallenge and RespondToAuthChallenge API operations.

[jhecking]

Thanks for the update! For us it comes a bit too late, as we have already implemented a different solution, similar to your earlier "DynamoDB" suggestion, but using the Cognito user pool itself to store the user's choice. It works, but I like this new solution using the additional "CHOOSE_EMAIL_OR_SMS" challenge better. Will keep it in mind for the next time something like this comes up.