Hi 鍾敏 — thanks for the clear description and the code sample. You’re asking about migrating a Web3Auth no-modal + JWT redirect flow from v9 to v10 — that’s a migration / integration question, so I gathered the relevant info and a suggested migration path below.
Parsed details from your message
- Issue type: Migration (v9 → v10) for no-modal / JWT redirect flow
- Platform / framework: Nuxt3
- SDKs / packages in your message:
- Code snippets: provided (init + loginWithAccessToken + logout)
- Links / images: none
Observations / likely cause
- You currently mix v9 (ethereum-provider) and v10 (modal). v10 revamped Web3Auth into a core + adapters model. The older “no-modal” style lives in older packages; in v10 the recommended way to run a no-UI (no-modal) redirect flow is to use Web3Auth Core + the OpenLogin adapter (configured for uxMode: “redirect”).
- Primary action: align package versions and switch to the v10 core + openlogin-adapter approach for a JWT redirect/no-modal UX.
Proposed migration steps (high level)
-
Align versions
-
Use Web3Auth Core + OpenLogin adapter for no-modal redirect
-
Login with your JWT (custom verifier)
- Use the openlogin adapter’s login flow for JWT (loginProvider: ‘jwt’) and pass extraLoginOptions: { id_token: accessToken, domain, userIdField, … } similar to what you already do. The adapter will perform the redirect when uxMode is redirect.
-
Callback handling
- On your redirect callback page (/auth-callback) call init() on Web3AuthCore so it can restore the session / complete the redirect flow (this is how it usually works with redirect flows in adapter-based systems).
Minimal example (v10-style, adapt to Nuxt3/service class)
-
Skeleton (pseudo-code to adapt into your class):
import { Web3Auth } from “@web3auth/core”
import { OpenloginAdapter } from “@web3auth/openlogin-adapter”const web3auth = new Web3Auth({
clientId,
chainConfig: { chainNamespace: “eip155”, chainId:0x${chainIdStr}},
web3AuthNetwork: web3AuthNetwork,
})const openloginAdapter = new OpenloginAdapter({
adapterSettings: {
uxMode: “redirect”,
redirectUrl:${window.location.origin}/auth-callback,
// loginConfig / verifier config may be required depending on your Web3Auth Console setup
},
loginConfig: {
jwt: {
verifier: this.config.public.web3AuthJwtVerifier, // your verifier name
},
},
})web3auth.configureAdapter(openloginAdapter)
await web3auth.init()// Trigger login (this will redirect when uxMode = redirect)
await web3auth.connectTo(“openlogin”, {
loginProvider: “jwt”,
extraLoginOptions: {
id_token: accessToken,
domain: window.location.origin,
userIdField: “sub”,
isUserIdCaseSensitive: true,
},
})
Notes and caveats
- The above code is a conceptual v10 pattern — adapter property names (loginConfig, adapterSettings, connectTo signature) are the correct high-level pieces to use, but small naming differences can exist between versions; check the v10 OpenLogin adapter docs for exact params.
- On redirect flows you typically do NOT get a provider object immediately — the browser will leave and then return to your callback route. On that page call init() (or the specific SDK redirect handler) to complete the session restore and obtain the provider.
- Make sure your Web3Auth Console (verifiers) is configured for your JWT verifier and that the verifier name matches what you pass.
What I recommend you do next (so I can help faster)
- Confirm your package.json (list of @web3auth/* versions) so I can confirm exact upgrade steps.
- Tell me whether you prefer using Web3Auth Core + OpenLogin adapter (no UI) in v10 — if yes I can give a more exact Nuxt3-ready code example for your class/service file.
- If you’ve tried a v10 approach and hit errors, share the browser console logs / screenshots from the callback and init steps.
If you want I can: (A) produce a complete Nuxt3 service class using the v10 core + openlogin-adapter that mirrors your current class (init, loginWithAccessToken, logout, callback handling), or (B) point to the specific v10 OpenLogin adapter docs. 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 biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours