Issue with Automatic TOTP MFA Unenrollment Triggered by 'REVERT_SECOND_FACTOR_ADDITION'

[saipraneethTLS]

I am working on a microservice, which is a Next.js-based application. I am encountering an issue where TOTP-based Multi-Factor Authentication (MFA) is successfully enabled for users in Firebase, but shortly afterward, it is automatically unenrolled. Initially, the TOTP MFA setup worked as expected, and I received an email notification confirming that MFA had been enabled for the account. However, immediately after the email is sent, a request is triggered in the logs labeled as "REVERT_SECOND_FACTOR_ADDITION" which removes the TOTP setup for the user.

Upon reviewing the logs, I noticed that this request aligns precisely with the time the email is received, suggesting a possible connection between the email notification and the automatic unenrollment. Additionally, the logs indicate a google.cloud.identitytoolkit.v1.ResetPassword action is being triggered at the same time.

I couldn't reproduce this issue, as I didn't face it in my private setup. Can anyone help me understand why this automatic unenrollment of MFA is occurring? Is there a specific Firebase configuration or security protocol that might be responsible for reverting the MFA setup? Could this behavior be tied to password resets or any other security mechanisms within Firebase or external sources?

Thank you in advance.

Log Details:

{
  "insertId": "__________",
  "jsonPayload": {
    "serviceName": "identitytoolkit.googleapis.com",
    "requestMetadata": {
      "callerSuppliedUserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6523.4 Safari/537.36,gzip(gfe),gzip(gfe)",
      "callerIp": "20.124.252.33"
    },
    "methodName": "google.cloud.identitytoolkit.v1.AccountManagementService.ResetPassword",
    "@type": "type.googleapis.com/google.cloud.identitytoolkit.logging.RequestLog",
    "response": {
      "requestType": "REVERT_SECOND_FACTOR_ADDITION",
      "email": "_______________",
      "mfaInfo": {
        "displayName": "_____________",
        "enrolledAt": "2024-10-21T21:40:25.556859Z",
        "mfaEnrollmentId": "____________-_",
        "totpInfo": {}
      },
      "@type": "type.googleapis.com/google.cloud.identitytoolkit.v1.ResetPasswordResponse",
      "kind": "identitytoolkit#ResetPasswordResponse"
    },
    "status": {}
  },
  "resource": {
    "type": "identitytoolkit_project",
    "labels": {
      "project_id": "_________________"
    }
  },
  "timestamp": "2024-10-21T21:44:10.582Z",
  "severity": "INFO",
  "logName": "projects/_________________/logs/identitytoolkit.googleapis.com%2Frequests",
  "receiveTimestamp": "2024-10-21T21:44:10.635212563Z"
}

[CatalanCabbage]

@saipraneethTLS did you find a fix?
We're running into an issue where it auto-removes TOTP MFA

[saipraneethTLS]

We are supposed to re authenticate the credential, that fix helped us. But, I don't know whether it is the right fix.

[anshulalloan]

@saipraneethTLS
by re-authenticate you mean, users should setup the multi-factor again by scanning the code (this was not sustainable) or we should turn off the firebase muti-factor feature and then re-configure?

[JaredEzz]

@saipraneethTLS
@anshulalloan

We were having this issue. The problem, we found, was that the enrollment email that is sent out gets validated by the email client and automatically triggers the unenroll. In the logs for identitytoolkit_project, you can see a google.cloud.identitytoolkit.v1.AccountManagementService.SetAccountInfo event that overwrites the user's MFA, removing it.

To solve this, we modified the action url in https://console.firebase.google.com/project/[project-id]/authentication/emails to return an intermediary page on our website that then links to the unenrollment link that was previously sent in the email. This prevents the user's email clients from accidentally unenrolling them when validating the link.

[CatalanCabbage]

Damned outlook scanning. Factored this into verification/enrollment link flows, forgot about unenrollment.

Good catch @JaredEzz, will check it out.