Thanks — you nailed the root cause. I searched the Embedded Wallets (Web3Auth) docs and internal knowledge and couldn’t find any SDK/constructor/init option to purge the cross-origin iframe (wallet.web3auth.io) session once the parent reports connected: false. That behavior matches your findings: the iframe maintains its own OAuth/session cache out of reach of the parent page for browser/OAuth security reasons.
Short actionable options/workarounds:
- User-side: ask affected users to clear site data for wallet.web3auth.io (or open an incognito window) — this is the only straightforward way to remove the iframe’s cached OAuth tokens today.
- Integration change: move to a headless/no-modal flow (custom auth/JWT or server-side verification) so you control auth/session lifecycle instead of relying on the modal iframe.
- Temporary dev workaround: use incognito/new browser profile when testing to avoid the persistent iframe session.
- Product route: file a feature request / bug with Web3Auth (or ask us to escalate) requesting a supported API to force-clear iframe sessions or a “always show fresh modal / ignore cached session” flag.
Next steps I can take: escalate this to the product/engineering team and attach your reproduction + logs, or help draft a concise feature request for Web3Auth. Which would you prefer?
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