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:
- 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.
- 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.
- 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