Cognito `AdminGetUser` property `UserMFASettingList` is empty when user pool has MFA set to REQUIRED

[CamMcRae]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

When a Cognito User Pool has MFA set to REQUIRED, the AdminGetUser API returns an empty UserMFASettingList array if the user has disabled their MFA methods (via AdminSetUserMFAPreference).

I cannot find anywhere in the documentation that notes this nuance, but I did find an issue from the archived aws-sdk repository that makes reference to this. I'd like to bring this back up for discussion, as I do not agree with the resolution of this being the expected behaviour as well as not making reference in the docs.

This issue leads to a behavioural dissonance between what the data says and what the user experiences and makes it impossible to make a conclusive determination about the current MFA status of a user.

• In a support role, it is more challenging to assist the user when you do not have access to all the data you should.
• A consuming application has no way to get the currently configured MFA methods, for use in custom guided workflows or data-driven UI elements.
• The AWS Cognito user management dashboard does not even reflect the correct values, nor does it follow a consistent pattern when viewing a user's MFA configuration
  • SMS is shown to be enabled, regardless of the enabled/disabled status and is instead driven by the existence of a phone number on the account
  • Other factors honour the enabled/disabled status with no indication that the method is still configured and potentially still in use.

Regression Issue

• Select this option if this issue appears to be a regression.

SDK version number

@aws-sdk/client-cloudwatch@3.1011.0

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v22.16.0

Reproduction Steps

Prerequisites:

• User has at least one MFA method setup
• User Pool has MFA set to REQUIRED

import { CognitoIdentityProvider } from '@aws-sdk/client-cognito-identity-provider';

const client = new CognitoIdentityProvider({
  ...
});

export const getUserMfaEnabled = async (username) => {
  await client.adminSetUserMFAPreference({
    UserPoolId: '<USER_POOL_ID>',
    Username: username,
    SMSMfaSettings: {
      Enabled: false
    },
    EmailMfaSettings: {
      Enabled: false
    },
    SoftwareTokenMfaSettings: {
      Enabled: false
    }
  });

  const user = await client.adminGetUser({
    UserPoolId: '<USER_POOL_ID>',
    Username: username
  });

  // returns empty array
  console.log(user.UserMFASettingList)
};

Observed Behavior

UserMFASettingList is empty.

Expected Behavior

UserMFASettingList reflect the values that be used during sign-in.

It may be more prudent to return more that just the list, so the consumer application can make its own determination with the data.

Possible Solution

Return UserMFASettingList with all MFA methods and the enabled/disabled status.

Additional Information/Context

No response

[aBurmeseDev]

Hi again @CamMcRae - thanks for sharing the details and finding that similar issue from aws-sdk. I looked into it internally and Cognito team confirmed this as an expected behavior. Here's what they said previously:

UserMFASettingList and PreferredMfaSetting are populated only if they are not null.
In the API reference, the wording for UserMFASettingList is: "The MFA options that are activated for the user. The possible values in this list are SMS_MFA and SOFTWARE_TOKEN_MFA" which means if MFA is activated, the above values are added to UserMFASettingList based on MFA settings.

We (SDK) can't make model changes but if you'd like me to check in with Cognito team on this again, I'd be happy to do so.

[CamMcRae]

Hello @aBurmeseDev, thanks again for the quick reponse. I do think that this behaviour should be improved, for everyone's benefit. At a minimum, I think that the data quality here should be reflective of the actual user behaviour. It is very bizarre to me that disabled MFA methods still impact user flow, while being effectively invisible. Even just exposing these MFA configurations would go a long way to making this more predictable.

I had a feeling this wasn't the correct place to log this, but couldn't find anywhere else. If there is, could you point me to it? I'd be happy to open it as an issue there.

[aBurmeseDev]

Hi @CamMcRae - I'll forward your feedback to the internal service team but you'll want to reach out to them directly via AWS Support. Since this's out of scope for SDK team here, I'm closing this issue. Thanks again for reaching out!

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.