TL;DR

• Orbis provides a demo coupled with open-source code snippets to showcase seamless Web3 social onboarding.

• Code snippets combine the Orbis SDK and each major authentication protocol including Privy, Lit Protocol (soon), Magic, and Web3Auth - all available in our Github repo.

• 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 SDK. The solutions we’ve integrated first include Privy, Lit Protocol (soon), Web3Auth, and Magic.

Demo access and developer recommendations

Orbis’ tech stack is provider-agnostic and uses battle-proven Web3 standards via the Ceramic 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 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 with Web3 check out the demo here

Alongside our interactive demo, we released an open-source repository 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 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)

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 with no additional prompts.

To learn more about Privy’s security, check out their docs.

Access the Orbis x Privy integration example in our Github repo here

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.

Check out our Orbis x Web3Auth integration example in our Github repo here

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 or a white-labeled experience using Dedicated Wallet.

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 for more details.

You can find Orbis x Magic Universal Wallet integration example in our Github repo here

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.

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