I’m developing a small website to test the social login feature of Web3Auth, currently on Sapphire DevNet. I’ve noticed that the address my application returns is different from the one returned by the Web3Auth demo, even though I’m using the same login credentials.
For context, I’m following the official repository examples and guides from the Web3Auth website. My goal is to fully understand this system so I can implement it in my future dApps.
I suspect this difference might be due to each website using a different Client ID—the demo website has its own Client ID, while my app has another. Could this be the reason for the discrepancy?
I would appreciate any clarification or guidance on this behavior.
Hi Francisco — thanks for the clear description, this is a great question and you’re on the right track. Tone: exploring an integration/behavior question (not a crash). Summary of what I see from your message:
Platform / Network: Web (Sapphire DevNet) — provided
SDK Version: not listed (please include if available)
Likely cause
Yes — different Client IDs are the most likely reason. Web3Auth (and similar auth/key-management providers) scopes the derived key material to the application/client. That means the same social login (Google/Twitter/etc.) will generally yield different private keys (and therefore different addresses) when used from different client IDs/apps. This is by design so one social account does not automatically expose the same key/address across unrelated apps.
The network (Sapphire DevNet) does not change how keys are derived — it only affects which chain you talk to once you have a key.
How you can confirm quickly
In your app and in the demo, capture the derived private key or the derived address immediately after login and compare them. If the private keys differ, the addresses will differ and that confirms client ID scoping.
As a test only, try using the demo client ID in your local app (or use your client ID on the demo site if possible) and log in. If the address changes to match the demo when the client ID is swapped, that proves the clientId is the factor. (Do not use someone else’s client ID in production.)
When to share more details (if you want deeper help)
SDK version you’re using
Your Web3Auth / MetaMask Embedded initialization snippet (the part that includes clientId, network/chain config)
Whether you’re using the same Web3Auth verifier/verifierId (sometimes different verifier configs can also affect output)
Any console log output or screenshots if behavior seems different than described
If you’d like, paste the init/login snippet (showing clientId and any verifier settings) and I’ll double-check it for anything that could cause additional differences. I can also suggest the exact code to compare private keys/addresses safely for debugging.
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
