Skip to main content

Backup Share for Applications - dApp Share

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 his 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 web platforms, the context remains within the browser only.

For the seamless login flow, we need to reconstruct Shares A, and B. Share A is managed by the login service and is provided on successful authentication. Whereas in web platforms, Share B 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, i.e., 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.

The dApp Share​

Once a user logs in, their details are returned as a response to the mobile application. The same response can be retrieved in web applications by utilizing the getUserInfo() function. Here's what the login response looks like for various platforms.

{
  "email": "john@gmail.com",
  "name": "John Dash",
  "profileImage": "https://lh3.googleusercontent.com/a/Ajjjsdsmdjmnm...",
  "aggregateVerifier": "tkey-google-lrc",
  "verifier": "torus",
  "verifierId": "john@gmail.com",
  "typeOfLogin": "google",
  "dappShare": "<24 words 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
}

In all of the responses, there is a field called dappShare, which is a 24-word seed phrase that can be used to reconstruct the private key. These dappShares supplement Share A and makeup half of the private key. The application can securely store the dApp share in its local storage. Users can use their social media accounts to obtain one share when logging in. The application provides the dApp Share, eliminating the need to store the share in the browser context and enabling users to log in smoothly. This is accomplished by passing the stored dApp share value in the login function (for Mobile SDKs) or the openlogin adapter configuration (for Web SDK).

note

It's important to understand that dappShare is exclusively for custom verifiers and can't be used with standard web3auth verifiers. Moreover, only users who have enabled MFA can access it. To use dApp Share, you need to use the custom authentication feature of Web3Auth. This guarantees that an application can only access the share corresponding to a user's private key.