Make email case insensitive on login?

Embedded Wallets (Web3Auth)
2

Hi Jack — thanks for the clear report, and sorry you’re getting support tickets because of this. I pulled the key details from your post and below I’ve summarized them for the support team and suggested next steps/workarounds.

Summary (what I see)

  • SDK: @web3auth/modal
  • SDK Version: 10.4.0
  • Platform: Web (browser) — using the Web3Auth modal flow
  • Flow snippet you’re using:
    const web3auth = new Web3Auth({options})
    await web3auth.init();
    if (!web3auth.connected) { await web3auth.connect(); }
    const { idToken } = await web3auth.getIdentityToken();
  • Issue: Emails with different case (hello@example.com vs Hello@example.com) result in different Web3Auth wallets/accounts. You don’t see an SDK or dashboard option to force case-insensitive email handling.

Quick explanation & likely cause

  • Web3Auth appears to treat the identifier used to derive/associate a user as a case-sensitive value coming from the identity provider / idToken. If the upstream OIDC/email provider returns the email with different casing, Web3Auth can end up creating distinct accounts.

Immediate workarounds and recommendations

  1. Short-term: Normalize in your app’s mapping layer
    • After login, read the idToken email claim and normalize it on your backend (e.g., email.toLowerCase()) and use that canonicalized email as the key in your own user DB. That prevents duplicate user records in your application. Note: you can’t retroactively merge on-chain wallets automatically — you’ll need a merge/link flow if you want to associate multiple wallets to one app account.
  2. Long-term / more robust: Use Custom Authentication (custom JWT / verifier)
    • If you need Web3Auth to derive the same key for an identifier you control, consider issuing your own signed JWT (custom verifier) where you set the subject/identifier to the normalized email. That lets you control the exact identifier used to create/lookup the Web3Auth account.
  3. Ask Web3Auth about server-side normalization
    • File a request with Web3Auth (or check their dashboard settings) for a feature to canonicalize email identifiers (lowercase) before account derivation. It’s reasonable to expect email normalization by default; they may have guidance or a setting.

What would help the support team (if you want them to dig in)

  • Which login adapters/providers are you using? (Google, email-passwordless, Discord, etc.)
  • Are you using a custom verifier or the default/social logins from the Web3Auth dashboard?
  • If possible, a sanitized idToken payload (the JWT claims — you can paste the decoded payload, removing anything secret). That will show what email value is being returned by the provider.
  • Any dashboard settings or custom verifier configuration you have set up.
  • Browser console logs or screenshots if you see any errors (optional here since this is more of an account-creation behavior than an error).

If you want, I can format the above as a short ticket for the Web3Auth support team or help you draft a minimal custom-JWT flow example to normalize the identifier. Which would you prefer, and which provider are you using for login?

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 biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours