Resend MFA Code API

[aoloo]

Is your feature request related to a problem? Please describe.
Our workflow MFA is required in Cognito via (SMS). The user enters the login username and password and is redirected to verify the MFA code page. Now comes the edge case where a user does not receive the MFA code due to network issues or other interference. Therefore we need to provide users with the option to resend an MFA code.

Describe the solution you'd like
A method to resend MFA Code due to some edge case a user does not receive a code within the initial sign In flow.
A similar hook to Auth.resendSignUp() but for MFA Code.

Describe alternatives you've considered
Calling the Auth.SignIn() to resend MFA Code is not ideal because signIn requires a username and password.

[elorzafe]

@aoloo

doing Auth.signIn(..) will resend the code, in that case you will need to store in memory the username and password for that purpose.

[aoloo]

@elorzafe @amhinson we are currently implementing that, but the authentication code does not always get sent. There some instances where calling Auth.signIn() does not work.

try {
  const user = await Auth.signIn(username,password);
} catch (err) {
   `Code was not sent successfully!`
 }

This is my current implementation within a on click event when a user clicks a resend-mfa code on a form. It will be really nice to have a resendMFA api call. This can benefit the community implementing MFA.

[aoloo]

@elorzafe Just to note when calling Auth.signIn it returns {"__type":"CodeMismatchException","message":"Invalid code or auth state for the user."}. So it is crucial that we have an api for re sending mfa authentication code.

[mitchgillin]

Seconding! This is an issue for me as well. Would be great if I could resend confirmation codes, without having to make users re-sign in.

[pinpointpanda]

Yeah, also seeing this. We'll workaround with posting to Auth.logIn again, but it does feel like there ought to be an api method for this - it's the only part of the sign up/sign in/reset password etc... workflows that doesn't have a re-send.

[cezarcarvalhaes]

This has been an issue for us for quite some time. I don't like having to hold on to a password in order to call Auth.signIn again for this feature, and asking users to sign in again is really clunky.

[aoloo]

@harrysolovay @elorzafe any movement on this?

[MaxwellOldshein]

Has anyone heard any update on this issue?

[martinlanglois]

Just want to add my name to the list of people who would need this feature.
I am not using the Amplify framework though. Only the php SDK. But it's visibly kind of all the same !

[chaawlaapooja]

Just want to add my name to the list of people who require this feature.
This is a blocker for my project.

[Thomsen-c]

This is a blocker on one of my projects as well.

[pedrohff360]

Same here... there's some update?

[justinslalom]

+1, this is a needed feature

[sfratini]

+1 This is very basic feature request at this point. Specially since we would like to send a code to actually validate the MFA before actually enabling it, to confirm the user has access to the phone/email.
AWS enabled it right away, without validating anything. And it is funny, since AWS actually ask you for TWO codes before enabling.

[tigrenok00]

+1

[eugendorin]

+1

[jwelfare]

+1

[44mkashif]

Any update on this issue? This is a blocker on one of my projects as well.

[AugustDev]

Need update on this

[Levisnkyyyy]

Seeking update as well

[madlerpar]

Is there any update on this? The given "workaround" of using Auth.SignIn() does not seem to actually work.

[Muzammil98]

+1, this is a needed feature

[ashwinchandran13]

CodeMismatchException: Invalid code or auth state for the user

A closed issue had a discussion what @aoloo described. Interestingly, the issue was closed without having a solution which rendered the discussion to be locked which lead me to posting the solution here but since anyone who is searching this issue is lead to here, here is the solution:

After receiving the code as SMS, do not trigger/call authenticate flow once again to send the SMS MFA code which causes the code to be invalidated and after getting the error you might notice another SMS MFA code being send which is due to the last authenticate call done to send initial SMS MFA code.

Instead create another path or method in which you can use either adminRespondToAuthChallenge or sendMFACode provided the Session parameter must have a value of session from the last authenticate call.

In my case, I had built REST API's which calls the authenticate function within a Lambda.

authenticate function is called after user submits email & password in frontend.

    import { CognitoUser } from 'amazon-cognito-identity-js';

    // inside authenticate lambda function
    const userData = {
       Username: user.email,
       Pool:     userPool
    };
    const cognitoUser = new CognitoUser(userData);
    cognitoUser.authenticateUser(authenticationDetails, {
      onSuccess: ...,
      onFailure: ...,
      mfaRequired: (challengeName, challengeParameters) => {
        const { Session } = cognitoUser;
        if (payload.mfa === undefined) {
         // returns mfaRequired response to frontend
          resolve({mfaRequired: true, session: Session}) 
        }
      }
   })

sendSMSMFA Lambda function which is called after user enters the code into the frontend

// inside sendSMSMFA function
const cognitoAdminUser = new CognitoIdentityServiceProvider({apiVersion: '2016-04-18'});
cognitoAdminUser.adminRespondToAuthChallenge({
 UserPoolId: user_pool_id,
 ClientId: client_id,
 ChallengeName: 'SMS_MFA',
 Session: payload.session,
 ChallengeResponses: {
   SMS_MFA_CODE: payload.mfaCode,
   USERNAME: payload.email
  },
 }, (err, data) => {
   if (err) {
    console.log('error responding to auth challenge', err);
    reject(err);
   } else {
      console.log('Successfully responded to auth challenge', data);
      const idToken = data.AuthenticationResult.IdToken;
      const AccessToken = data.AuthenticationResult.AccessToken;
      const refreshToken = data.AuthenticationResult.RefreshToken;
      resolve({token: idToken, access: AccessToken, refresh: refreshToken})
    }
   })

For anyone who wonders about why this isn't happening when using TOTP software token mehod is because the MFA code clock is separate of that of the cognito clock and thus there will always be a sync there even if codes are send in different authenticate calls but SMS MFA is really dependent on session id.

[117]

+1337

[felipecrestani]

??????

[valentinbeggi]

+1

[sagenate24]

+1

[elton-bz]

+1

[fcoradini]

+1

[Sc0ra]

+1

[owhittlef]

+1... blocker for my project.

I will use the workaround for now, but as others have said, I do not want to cache the user's password.

[evan-macgregor]

We were promised this was being worked on a almost two years ago.

Most recent action I see is a closure of the related issue in aws-sdk-js as "not planned" in September 2023.

This really is an essential (and easy to implement) feature. Too bad Amazon is a struggling 2-trillion-dollar company and doesn't have the resources to deal with the 500 open issues on this library that's arguably necessary to use their services.

[rohith-dev10]

this feature is a must have. Any updates??

[ashwinchandran13]

@evan-macgregor @rohith-dev10 I implemented this by doing a reauthentication. Is that not possible in your cases?

[kennydifiore]

Reauthentication is a disruptive and undesirable user experience. You would force the user to re-enter their credentials again. For security purposes, the user's credentials should never be stored by the web application. Every other IdP seems to support the ability to resend the MFA code because they offer API calls separate from Sign In/ Log In that allows the application to trigger a resend of the SMS MFA code. This seems like an essential feature that should be implemented.

Is the thought here that since SMS is the least secure of the MFA options that AWS would prefer us to migrate away from SMS and use TOTP apps or other alternatives?

[evan-macgregor]

@ashwinchandran13 Yeah, there's a workaround. That's not a feature or a fix, and as stated by many others, it's undesirable at best and insecure at worst. Don't pretend it's ok.

I, like many others, choose to use AWS because the marketing claims it is feature-complete. This is not the case, and many services offered by AWS are in such a state. You've wasted my time by letting me get this far into implementation, and if you decided that it's not that important, I guess I'll just have to change my implementation to use one of the many other companies that offer very similar features. Luckily I've written my code to easily strip out AWS, since I've recognized that this would likely happen.

[cpy-xcend]

It's incredibly disappointing. We chose Cognito based on AWS's branding, reputation, and the feature set promoted on their website. Resending a code is a basic, standard feature, and we didn't expect to encounter issues with it during the Cognito + Amply integration. We're seriously considering whether Cognito is the right fit for us moving forward. I hope other developers see this thread and avoid making the same mistake.

[ningchen-xcend]

I'm extremely frustrated and let down by this experience. We chose Cognito based on AWS's esteemed reputation. The ability to resend verification codes is a fundamental and essential feature, and encountering problems with it during the integration is both surprising and unacceptable. We are now seriously questioning whether Cognito can meet our needs moving forward. I urge other developers to heed this warning and consider alternative solutions to avoid facing similar issues.

[rongxcend]

As an ex-architect from AWS, it is really shame seeing the Customer Obsession principle is deteriorating, given such a basic and essential feature does not raise any attention to AWS. (4 years, what are you doing AWS?)

Of course there will be smarter person from AWS using 'has backbone' leadership principal to write a very long tech paper to illustrate/prove why such feature might not be a good idea to be implemented.
Nevertheless, it is an essential feature for a product claim to be IdP.

[MrHOY]

October 2024 and anything new?
Using a strict cache username and password and then calling API login again is not so good

[Schayimerdan]

I still use the Auth.signIn method to trigger the MFA process and resend the SMS code, but this solution is specifically designed for those who want to implement a resend MFA code feature reliably. Here's how I approached it:

1. Resend the SMS Code:

   • When the user requests to resend the MFA code, I call Auth.signIn again with the existing email and password.
   • This triggers AWS Cognito to resend the SMS for the MFA challenge.

2. Update the user Object:

   • After the resend operation, I update the user object with the latest session returned by Auth.signIn.

3. Verify the Code with Updated Session:

   • When the user submits the verification code, I use Auth.confirmSignIn with the updated user object to confirm the MFA code.

This solution avoids session mismatches and ensures that the resend and verification flows work seamlessly.

[lpv90]

still no solution from AWS?

[Yoac-eng]

How can this still be open 4 years later, seems like theres nothing yet