Skip to main content

v0.8.2

Add a phone number while setting up SMS MFA​

Until now, SMS MFA setup needed a phone already on the account. With signup.verificationMethod: 'email' (or a social signup) there is none, so a user forced into MFA setup who picked SMS hit PHONE_REQUIRED and had no way forward short of finishing sign-in another way and editing their profile.

The MFA_SETUP_REQUIRED challenge now says when a number is needed, and the setup request accepts it:

{
"challengeName": "MFA_SETUP_REQUIRED",
"challengeParameters": {
"allowedMethods": ["sms", "totp"],
"requiresPhoneCollection": "true"
}
}
if (requiresPhoneCollection(challenge)) {
await client.getSetupData(challenge.session, 'sms', { phoneNumber: '+14155552671' });
// { setupData: { maskedPhone: '+1***2671' } } — code sent, number saved (unverified)
}
await client.respondToChallenge({ session, type: 'MFA_SETUP_REQUIRED', method: 'sms', setupData: { code } });
// code verifies the phone, enrols the device, tokens issued

Same flag, same helper, same "send the number, then the code" shape as VERIFY_PHONE. Call getSetupData again with a different number to change it, or with none to resend. The authenticated mfa/setup-data route accepts setupData.phoneNumber the same way, so an account-settings page can enrol SMS without a phone on file too.

A number that differs from an already verified phone replaces it and resets verification, exactly as a profile update would; the phoneChanged hook fires so the account email can be told. See SMS MFA > Forced Setup.

Also in this release​

  • VERIFY_PHONE collection now checks phone uniqueness. A number already on another account returns PHONE_EXISTS unless signup.allowDuplicatePhones is set, as signup and profile update already did. Collection now shares their code path (PhoneVerificationService.setPhoneAndSendVerification()).
  • SMS verifySetup binds the device to the verified account phone, never to a number the client sends, and passes VERIFICATION_CODE_EXPIRED and VERIFICATION_TOO_MANY_ATTEMPTS through instead of reporting them as VERIFICATION_CODE_INVALID.
  • getSetupData() in the client SDKs takes an optional third setupData argument; the Angular setupMfaDevice() wrapper now forwards its setupData too. Existing calls are unchanged.

No action needed on upgrade.