Security and Feature parity concerns with Web3Auth Single Factor Auth Flutter SDK

Embedded Wallets (Web3Auth)
2

Hi Engels — thanks for the clear write-up and for flagging both the security concern and the feature gaps. You’re doing the right thing by checking this now. I’ve parsed what you shared and summarized next steps so our support team can act quickly.

Summary (what I extracted from your message)

  • SDK: Web3Auth Single Factor Auth Flutter SDK
  • Platform: Flutter (mobile)
  • SDK version: not provided — please share if available
  • Snippet you used to log in (you already provided):
    final loginParams = LoginParams(…)
    final sessionData = await _singleFactorAuthentication.connect(loginParams)
  • Behavior observed: sessionData.privateKey is returned (not Solana-compatible), and you currently use that private key with the Solana Dart package to compute a Solana wallet address
  • Links you provided: SessionData API (pub.dev) and Web3Auth Solana Provider (npm)

What I need from you (only if you can share — will help routing and diagnosis)

  • SDK version (from pubspec.yaml or the package info in your project)
  • The initialization snippet for SingleFactorAuthentication (if different from what you pasted) — e.g., how the SDK is instantiated/initialized
  • A redacted example of sessionData (you can mask >50% of any secrets) or confirm the privateKey format (hex, base64, array)
  • Any relevant app logs from the Flutter console showing the connect result (no screenshots required, plain text is fine)

Immediate guidance and proposed mitigations

  1. Security posture for private keys
  • If the SDK is returning a raw private key to your app, treat it as highly sensitive: do not log it, do not transmit it to your backend, and if you must persist it, keep it in platform secure storage (iOS Keychain / Android Keystore, ideally using secure enclave/strongbox). Better: do not persist at all and keep it in memory only for ephemeral operations, then zero it out.
  • If your goal is to never have the app access raw private keys, you need an API that performs signing (signMessage / signTransaction) inside the provider layer and returns signatures only. That avoids exposing the private key to the app.
  1. Feature parity (Solana support and signing delegation)
  • On Web (JS) Web3Auth provides a Solana provider (you referenced SolanaWallet.requestAccounts and signMessage). If the Flutter Single Factor Auth SDK does not expose signMessage/signTransaction or a requestAccounts-equivalent, you’ll need either:
    a) A Flutter SDK update from Web3Auth that exposes signing and account-request APIs (preferred), or
    b) A safe local strategy: derive a Solana-compatible key in a secure enclave and perform signing via a secure signer wrapper so the rest of your app never handles the raw key (still requires key material on-device), or
    c) Use the Web/JS integration (if feasible for your product) until the Flutter SDK provides parity.
  1. Docs availability
  • You noted the Flutter Single Factor Auth docs appear missing. I’ll flag that so the support team can confirm docs availability and restore or point you to the correct doc pages.

What I’ll do / what will happen next

  • I’ve captured this for the support team to investigate (your report will be tracked). A team member will review whether the SDK is designed to return private keys to the caller and whether signing delegation APIs are planned for the Flutter Single Factor SDK.

If you want faster help from the Web3Auth team directly

  • Consider filing a feature/security request with Web3Auth (include SDK version and a small redacted session dump). From your description, they should confirm whether the SDK is intended to return raw private key material and whether there is an alternative signing API.

Helpful links (from your message)

Would you like me to: (choose one)

    1. Forward this report to the MetaMask support team now (they’ll follow up and request any missing details), or
    1. Wait for you to paste the SDK version, init snippet, and a redacted sessionData, then I’ll attach that to the ticket (recommended), or
    1. I can provide a short example pattern for creating a secure local signer in Flutter (if you want a workaround now)

Again, thanks for bringing this up — if the SDK is returning private keys to the app by design, that’s an important security/UX concern and we’ll make sure it’s investigated. Which of the three next steps above would you like to take?

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