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

Developer Discussions
1

My question/concerns are in 2 parts first off is a security concern we currently have with the Web3Auth Single Factor Auth Flutter SDK

The Web3Auth Single Factor Auth Flutter SDK connect method, which is responsible for authenticating the user currently returns among other things the users Keypair which includes the users private and public address

final sessionData = await _singleFactorAuthentication.connect( loginParams, );

From this we can call sessionData.privateKey which returns non Solana compatible private key as reflected in the SessionData API reference

We are concerned that having access to the user private key or any user keys of some sort is a security issue that needs to be looked into, or perhaps you could point us to docs that specify best practices when using the Web3Auth Single Factor Auth Flutter SDK.

This brings me to my second question/concern- gaps in features across the Web3Auth JS SDK and Web3Auth Single Factor Auth Flutter SDK

Currently the Web3Auth Single Factor Auth Flutter SDK does not allow specification of the Chain Configuration, Chain Namespace, e.t.c. In the Web3Auth Flutter SDK we can only specify these:

final loginParams = LoginParams(
    verifier: …,
    verifierId: …,
    idToken: …,
    subVerifierInfoArray: [
        TorusSubVerifierInfo(
        …
        …,
        ),
    ],
);

final sessionData = await _singleFactorAuthentication.connect(
    loginParams,
);

The keypair returned from my description above is not compatible across several chains therefore for Solana we rely on the Solana dart package to get the users Solana compatible wallet address. However this process involves using the private key from the keypair returned by the connect method. So my questions are:

  1. Is there a way to delegate signing to Web3Auth Single Factor Auth Flutter SDK and never have neither access to the user private key nor have the SDK return any user private keys or other user secrets that should not be exposed in the first place. The Web3Auth Solana Provider npm package has a signMessage(msg) method that does this. If this is possible are there any docs on this
  2. There is no method to get Solana wallet address. The Web3Auth Solana Provider npm package has a SolanaWallet.requestAccounts() method to get the user Solana wallet address however there is no equivalent method in the Web3Auth Single Factor Auth Flutter SDK
  3. The docs for the Web3Auth Single Factor Auth Flutter SDK seems to have disappeared and we cannot find them anymore. This is making it hard for us to work on improvements and implement best practices on top of what we have so far
  4. Are there any plans to include more APIs to the Web3Auth Single Factor Auth Flutter SDK to make it easier to build on top of Solana
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

3

  1. Question: SDK version (from pubspec.yaml or the package info in your project)
    Answer: We are currently using the latest version of the Flutter SDK at the moment of writing single_factor_auth_flutter: ^7.0.2

  2. Question: The initialization snippet for SingleFactorAuthentication (if different from what you pasted) — e.g., how the SDK is instantiated/initialized
    Answer:
    final web3AuthOptions = Web3AuthOptions( network: Web3AuthNetwork.sapphire_mainnet,
    clientId: ...,
    sessionTime: 2592000,
    );

    await _singleFactorAuthentication.init(
    web3AuthOptions,
    );

  3. Question: A redacted example of sessionData (you can mask >50% of any secrets) or confirm the privateKey format (hex, base64, array)
    Answer:
    SessionData privateKey: e33…3bb63
    SessionData publicAddress: 0x19B…ed6

  4. Question: Any relevant app logs from the Flutter console showing the connect result (no screenshots required, plain text is fine)
    Answer:
    SessionData(
    privateKey: e33…3bb63,
    publicAddress: 0x19B…ed6,
    signatures: [
    {
    “data”: “eyJle…IifQ==”,
    “sig”: “b495…a1c”
    },
    {
    “data”:“ey…=”,
    “sig”:“bf…81c”
    },
    {
    “data”:“e…Q==”,
    “sig”:“bd…621c”
    }
    ],
    userInfo: UserInfo(
    email: te...@gmail.com,
    name: te...@gmail.com,
    profileImage: https://...e.png,
    aggregateVerifier: ...,
    verifier: sk...l,
    verifierId: te...@gmail.com,
    typeOfLogin: LoginType.jwt,
    ref: ...,
    accessToken: ...,
    idToken: ...,
    extraParams: ...,
    extraParamsPassed: ...,
    state: TorusGenericContainer(
    params: {}
    )
    )
    )

1 Like
4

Thanks for sharing all the details let us look into this please