[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
JavaScript Framework
Not applicable
Amplify APIs
Authentication
Amplify Categories
auth
Environment information
N/A
Describe the bug
When Customers configure userpool with MFA as required (both SMS and TOTP available) and phone number provided at registration, Cognito automatically enables SMS_MFA for that user and SMS_MFA challenge is returned at login. When user calls getUser API, SMS_MFA is not in the UserMfaSettingList even though it was activated for the user. From Api definition, UserMfaSettingList is the MFA options that are activated for the user. As a result of default activation from Cognito side, SMS_MFA should be present in the UserMfaSettingList. Otherwise, we don't have a reliable mechanism to detect SMS_MFA to display it in UI component that shows activated MFA methods for the user.
When Customers configure userpool with required MFA and TOTP is the only enabled method, TOTP is not added to MFA methods in console and to the UserMfaSettingList. Flow: user registers and sets up TOTP app. When verifySoftwareTOken Api is called, MFA TOTP status is verified if successful. When user tries to log in, they get 'SOFTWARE_TOKEN_MFA' challenge as a result which means that TOTP was activated. But when getUser call is made, TOTP is not reflected in UserMfaSettingList.
As a result of these two cases, we can't create a function that would reliably reflect MFA preferences for the user. (Auth.getPreferredMFA reflects incorrect information because of that)
Expected behavior
If MFA method is added to the userpool by default without Auth.setPreferredMFA method, it should be reflected in the UserMfaSettingList (getUser api)
When TOTP is added as MFA method at registration, there should be a way to add it to UserMfaSettingList (at this point, it requires user to be authenticated)
Before opening, please confirm:
JavaScript Framework
Not applicable
Amplify APIs
Authentication
Amplify Categories
auth
Environment information
N/A
Describe the bug
As a result of these two cases, we can't create a function that would reliably reflect MFA preferences for the user. (Auth.getPreferredMFA reflects incorrect information because of that)
Expected behavior
Reproduction steps
N/A
Code Snippet
No response
Log output
No response
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response