# Seamless onboarding for web3 social by Orbis By [charles.useorbis.eth](https://paragraph.com/@charles.useorbis) · 2023-09-08 --- TL;DR ----- * [Orbis](https://useorbis.com) provides a [**demo**](https://orbis-social-demo.vercel.app/) coupled with open-source code snippets to showcase seamless Web3 social onboarding. * Code snippets combine the [Orbis SDK](https://docs.useorbis.com) and each major authentication protocol including [Privy](https://privy.io), [Lit Protocol](https://litprotocol.com/) (soon), [Magic](https://magic.link/), and [Web3Auth](https://web3auth.io/) - all available in our [**Github repo**](https://github.com/OrbisWeb3/orbis-web2-auth-examples). * We’ve kept it simple, replace the API key for your desired provider and npm run _away_. Web3 Social onboarding is a bottleneck -------------------------------------- Today, non-web3 users face too much friction. Creating a traditional non-custodial wallet means managing seed phrases, private keys, and recovery methods. It’s daunting and requires extensive crypto knowledge. This steep learning curve is particularly challenging for those who just want to create a decentralized identity (user profile) or share content. In its current state, the process is far from user-friendly and efficient. Thankfully, a new breed of solutions has emerged, combining the simplicity of Web2 authentication and the power of Web3 wallets. These solutions offer familiar Web2 authentication methods, such as Sign in with Apple or Google, as well as OTP methods including SMS and email codes. This article explains each of the solution differences and how they easily integrate with the [Orbis](https://docs.useorbis.com) SDK. The solutions we’ve integrated first include [Privy](https://https//privy.io), [Lit Protocol](https://litprotocol.com) (soon), [Web3Auth](https://web3auth.io/), and [Magic](https://magic.link/). Demo access and developer recommendations ----------------------------------------- [Orbis](https://useorbis.com)’ tech stack is provider-agnostic and uses battle-proven Web3 standards via the [Ceramic](https://ceramic.network) network. Users authenticate and create their decentralized identity by signing a SIWX (Sign-in with X) message. Their DID is derived from the signing address using a method called DID:PKH. By not requiring special RPC methods or authentication forms, [Orbis](https://useorbis.com) is able to leverage all existing wallets across multiple blockchain ecosystems - as long as they can sign a message. To experience how easy it is to onboard [Orbis](https://useorbis.com) with Web3 check out the demo [**here**](https://orbis-social-demo.vercel.app/) ![](https://storage.googleapis.com/papyrus_images/20da3d50a7cee3b0a0638748d654c558b3b48314f085dcd3bd572f0e280749bb.png) Alongside our interactive demo, we released an [open-source repository](https://github.com/OrbisWeb3/orbis-web2-auth-examples) on GitHub containing each of the providers as a separate Vite project (Svelte, React). This allows you to check out exactly what’s needed to establish the connection to [Orbis](https://useorbis.com) as well as persist the session. Running each example is extremely simple: 1. Replace the API key for each provider (ie. for Web3Auth it can be found [here](https://github.com/OrbisWeb3/orbis-web2-auth-examples/blob/be7e3039502f6d8b50155af2991e8d14d9116f0a/web3auth/src/App.svelte#L24C8-L24C83)) 2. Run the below commands to install dependencies and start a live demo npm install npm run dev Deep-dive on each provider -------------------------- ### Privy Privy offers a React-first Plug & Play authentication - integration is as simple as using React hooks. Users can log in using their existing wallets or create a Privy wallet using one of many Web2 providers. Privy’s SDKs make it easy to handle multiple wallets, too! There is currently no headless integration method, the UI is **required**. Privy wallets are built on top of **Shamir’s Secret Sharing** (SSS). The setup is 2/3. * Share 1 is stored on the user’s device * Share 2 is encrypted by Privy and stored in their backend * Share 3 is encrypted using either user-provided entropy (secret phrase) or by leveraging an HSM. Once encrypted the share is stored by Privy. This setup allows for easy share recovery upon login with little to no secrets needing to be stored, depending on the setup chosen. Once the user logs in the shares are used to **reconstruct** the private key inside an isolated Privy iFrame. The is never persisted and liven in memory. It also never leaves the iFrame. Initial key generation happens inside the iFrame, too. Signing can happen with or without a user prompt, which allows seamless onboarding onto [Orbis](https://docs.useorbis.com) with no additional prompts. To learn more about Privy’s security, check out their [**docs**](https://docs.privy.io/guide/security). **Access the Orbis x Privy integration example in our Github repo** [**here**](https://github.com/OrbisWeb3/orbis-web2-auth-examples/tree/main/privy) ### Web3Auth (ex Torus) Web3Auth provides a Web3 wallet infrastructure combined with a number of Web2 providers (adapters) which can be used to authenticate users. It's built on top of the Torus network. Using Web3Auth’s UI is **optional**. They also offer BYOA (bring your own auth), which allows you to integrate it seamlessly no matter the authentication provider you want to use (or are already using). Developers can choose the default level of security required to access their application based on the nature of assets kept in the wallet. Users can opt-in for higher security, too! Wallet management options are: * **Single share** * stored by the Torus network * easiest for the end user, but semi-custodial (authentication provider could technically recover the share) * The private key **is reconstructed** * **Shamir’s Secret Sharing** * default threshold is 2/3, but can be extended to n/m, the private key **is reconstructed** * Share 1 stored by the Torus network * Share 2 stored on the user’s device * Share 3 (recovery share) is encrypted and stored by the user * **Multi-party Computation (MPC)** * This is Web3Auth’s new product, it’s in a public beta * The number of parties (shares) is configurable, the same as SSS * The main benefit is the user’s private key does **not get reconstructed** To learn more about Web3Auth and the differences between different wallet management strategies check out their [docs](https://web3auth.io/docs/infrastructure/). **Check out our Orbis x Web3Auth integration example in our Github repo** [**here**](https://github.com/OrbisWeb3/orbis-web2-auth-examples/tree/main/web3auth) ### Magic Magic simplifies Web3 wallet creation using magic links (links sent to the user’s email, clicking them authenticates the user) and Web2 social providers. Integration options include their UI Plug & Play product [Universal Wallet](https://magic.link/docs/universal/overview) or a white-labeled experience using [Dedicated Wallet](https://magic.link/docs/dedicated/overview). Unlike other solutions, Magic does not employ SSS or MPC. Instead, their (patent-pending) setup looks like this: * On first login, the user’s private key is generated locally * Each user gets a dedicated AWS KMS which is used to encrypt the generated private key * An encrypted private key is stored by Magic * Each additional login fetches the key from Magic and decrypts it using the KMS All operations happen inside Magic’s isolated iFrame. The key is never persisted, but it is available in memory. Check out Magic’s [security documentation](https://magic.link/docs/home/security) for more details. **You can find Orbis x Magic Universal Wallet integration example in our Github repo** [**here**](https://github.com/OrbisWeb3/orbis-web2-auth-examples/tree/main/magic) ### Lit Protocol (PKPs) Lit Programmable Key Pairs (PKPs) leverage Lit's existing distributed key management infrastructure. Unlike other multi-factor solutions, **all** shares are stored inside Lit's network and distributed among nodes. Key generation is done in a distributed way (DKG). The key is **never reconstructed** and it never leaves the network. The threshold is 2/3 (two-thirds) of all the nodes in your subnet (network). This setup provides the security benefits of MPC with no user-error risks, as none of the shares are persisted or encrypted by the user. Each PKP is represented by an NFT minted on Chronicle - Lit’s OP stack-based L2 anchored in Polygon. Chronicle is also used for node orchestration and staking of LIT tokens (soon). The “Programmable” part of Lit’s wallets is powered by Lit Actions (which dictate the wallet’s behavior). Lit Actions are Javascript programs stored on IPFS. Javascript execution is done by Lit nodes inside an isolated Deno environment. Developers define authentication methods using Lit Actions. They can be as simple or advanced as you want, including multi-factor authentication, oAuth, WebAuthn and BYOA. They can also dictate wallet behavior, such as which level of authentication is required to perform a signing or transfer operation. Lit PKPs are built in a white-label way and **do not** contain UI. Lit PKPs are currently available on the Serrano testnet and are scheduled to come to mainnet soon. You can read more about Lit PKPs and Lit Protocol in their [developer docs](https://developer.litprotocol.com/v2/pkp/intro). **Orbis x Lit PKPs integration example will be available when the feature leaves testnet phase.** By collaborating with leading authentication protocols, we're bridging the gap, making web3 technologies approachable for everyone. If you'd like more information or have any questions, please don't hesitate to contact us. Made with ❤️ by Orbis Dev Rel **Donat** --- *Originally published on [charles.useorbis.eth](https://paragraph.com/@charles.useorbis/seamless-onboarding-for-web3-social-by-orbis)*