Skip to main content

Using dApp Share in PnP Flutter SDK

Web3Auth Infrastructure at a glance​

If you go through the Web3Auth infrastructure you'll notice that to enable the non custodiality of Web3Auth, we split the private key into multiple parts, ie. shares. These shares are a part of the off chain multisig, where multiple shares are stored in different places and can be used to reconstruct the private key dynamically in the user's frontend application. For a glance at the structure of the shares, these are the following:

  1. ShareA is managed by a login service via node operators: This share is further split amongst a network of nodes and retrieved via conventional authentication flows.
  2. ShareB is stored on the user's device: Implementation is device and system specific. For example, on mobile devices, the share could be stored in device storage secured via biometrics.
  3. ShareC is a recovery share: An extra share to be kept by the user, possibly kept on a separate device, downloaded or based on user input with enough entropy (eg. password, security questions, hardware device etc.).

Similar to existing 2FA systems, a user needs to prove ownership of at least 2 out of 3 (2/3) shares, in order to retrieve their private key. This initial setup provides several benefits.

The User Experience in Mobile Platforms​

The user experience on mobile platforms is very different from the web platforms. This is because the user has to be redirected to a browser where they can login using their socials and then back to the app once they have been successfully authenticated. This user experience shifts the context between two applications, whereas, in the web platforms, the context remains within the browser only.

For the seamless login flow, we need to reconstruct the Shares A and B. Share B is managed by the login service and is provided on successful authentication. Whereas in web platforms, Share A is stored in the browser context. We can still store it in the browser context for mobile devices, but this has a few risks like users accidentally deleting browser data. This is a bigger problem in mobile devices since the user doesn't realize that the browser is being used to login within the app and clearing the browser data can cause their logins to fail. Hence, to tackle this issue, Web3Auth issues a dApp Share, ie. a backup share that can be stored by the app developer directly within their application and used to reconstruct the private key after successful login by the user.

dApp Share in Flutter​

Web3Auth issues a dApp Share, ie. a backup share that can be stored by the app developer directly within their application and used to reconstruct the private key after successful login by the user.

After a successful login from a user, the user details are returned as a response to the application on mobile devices.

Sample Response in Flutter​

{
  "userInfo": {
    "email": "w3a-heroes@web3auth.com",
    "name": "Web3Auth Heroes",
    "profileImage": "https://lh3.googleusercontent.com/a/Ajjjsdsmdjmnm...",
    "verifier": "torus",
    "verifierId": "w3a-heroes@web3auth.com",
    "typeOfLogin": "google",
    "aggregateVerifier": "w3a-google-sapphire",
    "dappShare": "", // 24 words of seed phrase will be sent only incase of custom verifiers
    "idToken": "<jwtToken issued by Web3Auth>",
    "oAuthIdToken": "<jwtToken issued by OAuth Provider>", // will be sent only incase of custom verifiers
    "oAuthAccessToken": "<accessToken issued by OAuth Provider>", // will be sent only incase of custom verifiers
    "isMfaEnabled": false // Returns whether the user has enabled MFA or not
  }
}

If you notice, the reponses has a field called dappShare which is a 24 words seed phrase that can be used to reconstruct the private key. This dappShare is a supplement to the Share A and represents half of the private key. The application can store the dApp share in its own application's local storage safely.

Now, while logging in, the user can use their social accounts to obtain one share, and the application provides the dApp Share, removing the need to store the share in the browser context and enabling the user to login seamlessly. This can be done by passing over the stored dApp share value in the login function.

note

One major thing to note here is that the dappShare is only available for custom verifiers and not the standard web3auth verifiers. This is done to make sure that an application only has access to the corresponding share to the private key of their application's user. Hence, to use dApp Share, one has to use the custom authentication feature of Web3Auth. Also, the dApp Share is only returned to users who have enabled 2FA to their account.

final Web3AuthResponse response = await Web3AuthFlutter.login(LoginParams(
  loginProvider: Provider.google,
  dappShare: "<24 words seed phrase>"
));

Example​

Future<void> initWeb3Auth() async {
  HashMap themeMap = HashMap<String, String>();
  themeMap['primary'] = "#229954";

  Uri redirectUrl;
  if (Platform.isAndroid) {
    redirectUrl = Uri.parse('{SCHEME}://{HOST}/auth');
    // w3a://com.example.w3aflutter/auth
  } else if (Platform.isIOS) {
    redirectUrl = Uri.parse('{bundleId}://auth');
    // com.example.w3aflutter://openlogin
  } else {
    throw UnKnownException('Unknown platform');
  }

  await Web3AuthFlutter.init(
    Web3AuthOptions(
      clientId: "WEB3AUTH_CLIENT_ID",
      network: Network.testnet,
      redirectUrl: redirectUrl,
    ),
  );
}

final Web3AuthResponse response = await Web3AuthFlutter.login(LoginParams(
  loginProvider: Provider.google,
  dappShare: "<24 words seed phrase>"
));