Social Login
Users who are new in Web3 do not have wallets and require a progress onboarding flow. To streamline this onboarding we offer the ability to log in with Social Accounts on Google/Twitter and others in a self-custodial way. We have integrated with Web3Auth to enable the social login feature. For AsteroidKit users, it's a simple click on a dashboard to enable it.
With Web3Auth private key is split into multiple pieces that enable full self-custody for your end users.
How to enable social login?
Allowed Domains
For security purposes social authenticated works on localhost and allowed domains, please add your domain in the setting as well. Note, that it may take a few hours to sync.
How does it work for the user?
Please, check out our demo app to see how it works from the user's perspective.
How is key storage is implemented?
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.
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.
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.
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.
Non-custodial
Using Web3Auth, the user is always in control of ownership and access to their cryptographic key pair. Login services only ever have access to one share, and thus it's not possible for the provider to retrieve the user's private key on their own.
Feels like Web 2.0 login flows
On a day-to-day basis Web3Auth allows access to a users key pair through flows indistinguishable from Web2.0 logins, contributing to greatly improving user experience and onboarding
Improvements to key recovery and redundancy
In the event of a lost device/share, there is redundancy built into the share threshold such that a user can still recover their key. It is also possible to refresh shares such that lost shares are revoked.
This is an improvement over writing down a seed phrase on a piece of paper, since losing the seed phrase gives complete access to the private key. Losing a share, however, is acceptable as long as the user does not lose more than one share without refreshing his existing shares.
Please refer to the original web3auth documentation for more details:
Last updated
