Hi! I'm currently building a mobile wallet and looking for some clarification about the dApp share (https://web3auth.io/docs/dapp-share)
At the bottom of the doc it says dappShare is only available for custom verifiers and not the standard web3auth verifiers but the reasoning is a bit vague. Could anyone help me better understand why this is the case?
Hey @hazim-j
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.
Here,
standard web3auth verifiersis the default verifier you get for the Web3Auth Plug n Play UI SDK
Also, the dApp Share is only returned to users who have enabled 2FA to their account.
To get dapp share in Android, one has to initialise web3auth like below:
web3Auth = Web3Auth ( Web3AuthOptions ( context = this, clientId = getString (R.string.web3auth_project_id), network = Web3Auth.Network.MAINNET, redirectUrl = Uri.parse ("{YOUR_APP_PACKAGE_NAME}://auth"), // Optional loginConfig object loginConfig = hashMapOf("google" to LoginConfigItem( verifier = "verifier-name", // get it from web3auth dashboard typeOfLogin = TypeOfLogin.GOOGLE, name = "Custom Google Login", clientId = getString(R.string.web3auth_google_client_id) // google's client id )) ) )
Web3Auth issues a dApp Share in the response, 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.
See https://web3auth.io/docs/sdk/android/dapp-share#example to know more on how to use dapp share in subsequent logins.
Hi, first of thanks for asking this question, So before biting the bullet to answer why dappShare is returned for custom verifiers and how dapps can use this share, I will make some effort to describe what verifier is and what is the difference between custom and default verifiers.
Verifier:- A verifier is a piece of information about the OAuth provider being used by the application which is queried by web3auth auth network nodes from a smart contract deployed on the Ethereum blockchain to verify the jwt token.
Default verifiers:- These are the verifiers associated with OAuth providers which are owned and managed by web3auth's account.
Custom verifiers:- If you want to manage your OAuth providers yourself or maybe want to use some proxy providers like firebase, aws cognito, auth0 etc, you can create your custom verifiers from the developer dashboard. https://dashboard.web3auth.io.
As you already know that a user's private key in web3auth gets split into various shares and the user needs only 2 of those shares to log in.
Dapp share is one of those shares which is generated for a user account.
Dapp share is generated only after the user enables MFA, so if the user has not enabled it will not be returned to dapp.
Another point to consider is that this share is generated only for custom verifiers. You may ask why!!.
Before answering this, I would like to clear up another "why", why is dapp share is required at all even for custom verifiers !!.
User logs in to a new browser with social login + backup token.
Now let's say, User comes back after 2 days and tries to login in same browser, now we need 2 shares from user right so how can it be achieved with out compromising the user login experience:-
So while storing the device share in local storage of web3auth's browser domain we also return the same share to dapp which dapp can manage and we call it dapp share. As a dapp you are not limited to but you can:-
- store dapp share as an encrypted backup in your server.
- store it as a backup on user's apple cloud.
- store it in the android/ios key store if you are a mobile app.
Because default verifiers are shared among various applications.
Let's say if two applications A and B are using default verifiers, then a user "x" can log in to both applications with the same shares.
Now let's assume if would have returned dapp share for default verifiers then both applications A and B can access one common share of the user's account. In this case, if any of A or B got malicious and got access to the user's social login account or any other share then the malicious application can affect the security of rest of the applications which are using default verifiers as well. So it seems a better option to not return dapp share at all for default verifiers and hence we don't return it.
I hope this answers your question, feel free to shoot any further queries.