Skip to main content

Using dApp Share in PnP Unity 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, called 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 stored on the user's device: The Implementation is device and system specific. For example, on mobile devices, the share could be stored in device storage secured via biometrics.
  2. ShareB 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.
  3. ShareC is a recovery share: An extra share to be kept by the user, possibly stored 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/ Native OS Platforms​

The user experience in gaming & native OS 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 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 other devices, but this has a few risks, like user accidently deleting browser data. This is a bigger problem while using native platform application, since the user doesn't realise 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 Unity​

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 Unity​

{
  "ed25519PrivKey": "666523652352635....",
  "privKey": "0ajjsdsd....",
  "coreKitKey": "0ajjsdsd....",
  "coreKitEd25519PrivKey": "666523652352635....",
  "sessionId": "....",
  "error": "....",
  "userInfo": {
    "aggregateVerifier": "w3a-google",
    "email": "john@gmail.com",
    "name": "John Dash",
    "profileImage": "https://lh3.googleusercontent.com/a/Ajjjsdsmdjmnm...",
    "typeOfLogin": "google",
    "verifier": "torus",
    "verifierId": "john@gmail.com",
    "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
    "isMfaEnabled": true // returns true if user has enabled mfa
  }
}

If you notice, the response 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 suplement to the Share A and represents half of the private key. The application can store the dApp share in their own application 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 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 in 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.

Example​

public void login()
{
    var selectedProvider = Provider.GOOGLE;
    var options = new LoginParams()
    {
      loginProvider = selectedProvider,
		dappShare = "enter your dapp share"
    };
    web3Auth.login(options);
}