Multiple issues with web3auth login

Embedded Wallets (Web3Auth)
1

Hi, I am from Avici (avici.money), a self-custodial Internet finance app. We have been using Web3Auth for authentication across our Flutter mobile app. We are reporting multiple active issues affecting our users on the Web3Auth Passwordless login flow, with several users currently locked out of accounts holding significant balances.

Issue 1: Account mismatch error despite valid authenticator code

Users who have MFA configured are reaching the “New device detected” screen at auth.web3auth.io, entering their correct authenticator code, and receiving the following error:

“Account mismatch, please continue with one you set as a social recovery factor.”

The social login option on the same screen correctly displays their registered email and is pre-selected, yet the flow still fails. These users have a valid auth code and their social login identity is correctly reflected in the UI. They are still being blocked.

image
image589×1280 60.1 KB

Issue 2: MFA screen shown to users who never set up MFA

Multiple users who logged in via email and never configured any MFA or 2FA are being presented with the “New device detected” MFA verification screen. They have no recovery phrase, no passkey, no authenticator app and no secondary device set up, so they have no way to proceed.

A partial workaround was identified for one user: logging in directly via accounts.web3auth.io, setting up a new MFA factor there, and then using that factor in the app. This is not a scalable fix and places an unacceptable burden on users.

We need to understand why MFA is being triggered for accounts that have no MFA configured, and whether this is related to a session or device fingerprint change on your end.

Issue 3: Google email change creating a new account instead of preserving the existing one

A user changed their Google account email address. Upon next login, Web3Auth created a brand new account rather than recognizing the same underlying Google identity.

Google assigns a persistent unique user ID (the sub claim in the OIDC token) that does not change when a user changes their email. Web3Auth should be keying account identity on this sub value, not the email string. The user logs into Google on all other platforms without any issue, confirming this is specific to how Web3Auth handles the identity mapping.

Additionally, Google now prevents users from reverting an email change for 12 months, so the user cannot undo this on their end. They are locked out of an account with a sizeable balance.

The email addresses of all affected users can be shared over DMs if needed.

2

Thanks — I’m from the MetaMask / Web3Auth team. This is an error report (not a feature ask). Short summary of probable causes and immediate actions, and what I need from you to escalate.

Quick takeaways (what’s most likely):

  • Issue 1 (Account mismatch): usually a factor / key-share reconstruction mismatch. That happens when the verifier combination or verifier config (verifier name, clientId, network) differs from the original signup flow. Even a different verifier name or client ID will break reconstruction.
  • Issue 2 (MFA shown when never set): typically occurs when the device share is missing (new device / cleared storage) but the account was created without an explicit recovery factor. The system then prompts MFA but no usable factor exists.
  • Issue 3 (Google email change → new account): this happens when identity is keyed on email instead of Google’s stable OIDC sub. Web3Auth must be configured to use Google OIDC (sub) as the stable identifier.

Immediate actions you can take now:

  1. Verify verifier configuration across all builds/environments: same verifier name, clientId, network (mainnet/testnet), and same hosted UI vs embedded config. Mismatches cause Issue 1.
  2. Confirm you’re using Google as an OIDC verifier (not treating Google login as an email-passwordless flow). If you’re mapping on email, change to OIDC sub mapping — this addresses Issue 3.
  3. For users blocked by missing MFA, ask them to add a recovery factor at accounts.web3auth.io (works as a temporary workaround). For a scalable fix, require/enforce MFA enrollment on signup or add explicit recovery factors.

What I need from you to investigate and escalate (please DM these due to sensitivity):

  • SDK / package and exact version you’re using in Flutter.
  • Are you using the hosted accounts/web UI or embedded Web3Auth flows inside the app (webview vs native)?
  • Exact verifier names configured in your dashboard (e.g., google, email_passwordless, custom_verifier) and clientId + network for each environment.
  • Example affected user emails (DM only), timestamps of failed attempts, and any server / auth logs or error IDs you have.
  • If available, a short reproducible flow for one user (steps they took).

If you share the above (esp. verifier names + SDK version + a couple affected emails via DM), I’ll escalate to engineering right away to inspect account mappings, factor state, and device-share records. If you prefer, I can start by checking your verifier configuration first and point out exact mismatches.

If you want me to proceed, share the verifier names and SDK version here and DM the user emails — I’ll take it to the team for deeper logs and a remediation plan.

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours