Hi Umair — thanks for the clear write-up, this is very helpful. I understand you upgraded to Web3Auth v10 (modal) and the OTP/email login opens in the same tab but does not redirect back to the originating URL after the OTP step. I’ll summarize what I’m seeing and list quick checks and the minimal items our support team will need to investigate.
Summary of extracted details
- SDK / integration: Web3Auth (modal) v10
- Packages & versions you provided: @web3auth/auth ^10.6.0, @web3auth/modal ^10.6.0, @web3auth/no-modal ^10.6.0 (plus base packages 9.7.0)
- Platform: Web (browser / Next.js — you reference window.location)
- Config you tried (examples included): uiConfig: { uxMode: “redirect” }, passing redirectUrl via login() and via adapterSettings in older no-modal code
- Symptom: after OTP flow the final redirect does not return to the redirectUrl you provided (works in older version)
Quick checks / likely causes to confirm (most common):
- Redirect URL must be registered in Web3Auth dashboard
- Web3Auth requires the exact redirect URI to be allowed/whitelisted in your app settings. Make sure the exact absolute URL (including path if used, e.g. https://example.com/b) is registered.
- Ensure the redirect URL exactly matches (protocol + host + path). No trailing slash mismatch, exact path match, same origin.
- UX mode consistency
- You set uiConfig: { uxMode: “redirect” } — that is correct for a redirect flow. Make sure there is not another place overriding it.
- Where to pass redirect URL
- Passing a redirectUrl in the login/connect call is fine, but it must match the dashboard-registered URL. If you set a redirect URL dynamically (window.location.pathname logic) ensure that every possible value is also added to dashboard or that you only use one canonical redirect URL.
- Flow differences between modal and no-modal
- The modal/hosted flow may behave slightly differently than the older no-modal adapter. If you previously relied on the adapterSettings.redirectUrl behavior, double-check v10 modal usage for where redirect must be set (dashboard + login/connect options).
What we need from you (minimal, to avoid extra back-and-forth)
- Confirm the exact redirect URL you expect (example: https://yourdomain.com or https://yourdomain.com/b) and confirm whether that exact URL is registered in the Web3Auth dashboard.
- The full initialization & login snippet you’re using in v10 (you posted parts — please paste the exact code you call at startup and the exact login/connect call you make).
- A browser console screenshot or network log from a failed flow (especially any messages about missing/invalid redirect_uri or cross-origin failures). If you can capture the final redirected URL (or lack of it) that’s helpful.
Short troubleshooting steps you can try right now
- Register the exact redirect URL in the Web3Auth dashboard (if you haven’t already) and test with that single URL (avoid dynamic per-path redirects initially).
- Use an absolute redirect URL string when calling login/connect (e.g. redirectUrl: window.location.origin + “/b”) and make sure this exact URL is in the dashboard.
- Try a minimal repro page (simple HTML/JS) with uxMode: “redirect” and the redirectUrl set to a known whitelisted URL — this isolates Next.js routing concerns.
If you’d like, paste the exact v10 init + login/connect calls here and confirm whether the redirect URL is whitelisted in the Web3Auth dashboard. Once you provide that (and a console/network capture if available) I’ll pass it to the support team in a concise ticket so they can diagnose further.
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