Hi Alex — thanks for the detailed report, this is very helpful. I pulled the key info below so the support team can quickly triage, and I added a few focused checks and next steps you can try now.
Extracted details (for the support team)
- SDK: Web3AuthNoModal (Web3Auth SDK)
- SDK version: @web3auth/modal v10.10.0 (you stated v10.10.0)
- Platform: Ionic app (Ionic v8.7.8). Mobile deep link (redirectUrl: com.zertipower.app://zertipower). uxMode: “redirect”
- Current behavior: popup flow works (returns idToken). Redirect flow returns a Base64-encoded string to the app on deep link, then web3auth.init() runs and calls the configuration endpoint which shows whitelist: { urls: null, signed_urls: {} } and web3auth.status remains “connecting”.
Likely causes / what to check
-
Deep-link handling: make sure the app actually receives the full callback URL on open (not just a trimmed Base64 fragment). In Capacitor/ Cordova/ native you must register the scheme (Info.plist, AndroidManifest, capacitor.config) and handle the app-open URL event. If the SDK doesn’t get the original callback URL the redirect flow can’t finish.
-
Exact redirect URL match: the redirect URL must match exactly what’s whitelisted in your Web3Auth dashboard (including scheme, host, path, trailing slash). Confirm com.zertipower.app://zertipower is listed exactly.
-
Finalizing the redirect flow: Unlike popup mode (where the SDK gets the response in-window), redirect mode requires the app to hand the callback data (the returned URL or Base64 payload) back to the SDK so it can decode/exchange for tokens. If your app is only calling web3auth.init() but not providing the original callback URL or letting the SDK process the redirect result, the status may hang at “connecting.”
Quick actionable steps you can try now
-
Confirm the app receives the full deep link when returning from the browser. For Capacitor, add an appUrlOpen listener:
- App.addListener(‘appUrlOpen’, ({ url }) => { console.log(‘opened with url’, url) })
- If you only see a Base64 fragment, log the entire URL and copy it.
-
Decode the Base64 payload to inspect what it contains (idToken, code, state, etc):
- In JS: const decoded = atob(base64String); console.log(decoded)
- If it already contains an idToken you can use it directly with your backend login flow (as you do in popup mode).
-
Ensure web3auth.init() is called as early as possible after app open, and that the SDK is given access to the original callback URL so it can complete the redirect flow. If the SDK exposes a “handle redirect” method, call that (or call connect() after init) — if you’re not sure which SDK method completes the redirect, share the Web3Auth initialization/entry code and I’ll point to the exact call.
-
Double-check Web3Auth dashboard: the redirect URL must be present under the correct environment (testing/sapphire_devnet) and for the embedded/redirect flow. The configuration response you pasted shows whitelist.urls: null — that indicates the SDK/endpoint didn’t pick up your whitelisted URLs for that environment/build env.
What I need from you (minimal):
- Confirm mobile OS (iOS, Android, or both) and whether you’re using Capacitor or Cordova.
- Do you see the full deep link URL in logs when the app opens? If yes, paste the decoded Base64 payload (or a screenshot). If no, tell me what you see.
- If possible, share the appUrlOpen/URL-handling snippet where you capture the deep link (or confirm you don’t yet have one).
If you prefer I can open a support ticket for the Web3Auth/dashboard team — I’ll include the details above plus any logs/payload you provide. If you share the decoded payload or the exact URL received by the app I can tell you whether it already contains an idToken or whether the SDK must perform an exchange.
Thanks — once you paste the small missing bits (OS + whether using Capacitor/Cordova + the decoded payload or the open-url log) I’ll suggest the exact code changes or file the issue with the right attachments so the SDK team can investigate quickly.
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