Biconomy SDK

Social Login

Most Web3 applications these days require a Web3 wallet, which serves as a Web3 authentication or Web3 login tool. However, since many of your users might still be unfamiliar with wallets, this could prove to be a blocker for onboarding new users. Therefore, combining traditional social sign-in and Web3 login would be a game-changer.
We work closely with Web3Auth to bring you social login via the Biconomy SDK. Our non-custodial social login flow contributes to much-improved user experience and onboarding. The user is always in control of ownership and access to their cryptographic key pair. If you have an existing user base it is very easy to plugin & use. Zero migration necessary.
If you wish to skip the explanation of how Social Login works via BiconomySDK, you can directly navigate to Enable Social Logins within your dApp.

Flow Explained

A user can login to your dApp either via social login or by connecting his external wallet. In social login he may sign in via Google, Facebook or email. A unique private key is generated for each user via Web3Auth. Using this key he can sign transactions without any wallet pop-ups or context switching. As long as the email is same, same account will be generated for all social accounts.
Please Note: Biconomy does not store any private keys.

Key Infrastructure

With Web3Auth, users handle keys similar to a multi-factor account, where they use their OAuth login, devices and other factors to manage their key pairs. In this example, the user starts by generating a 2 out of 3 (2/3) Shamir Secret Sharing. This gives the user three shares: ShareA, ShareB, and ShareC.
  1. 1.
    ShareA 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.
  2. 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. 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.
In order to enable this flow, please check out our Guide to Enable social logins within your dApp.