App developers looking to add passwordless, Touch/FaceID capabilities to their app experience can now do so. With OpenLogin, dapps will benefit from:
- Device native biometrics: Familiar Face/TouchID logins to your application.
- Social Account SSO, & Passwordless flows: Users can register via Google, Twitter, Github, and email verification.
- Connect with any Avalanche Library: pluggable into any Web3 supported SDK
- Non-Custodial PKI Architecture: Secured on a mixture of user devices and authentication methods, the architecture protects vital user information against conventional data breaches.
- Customizable and Custom Logins: OpenLogin blends right into your application without disrupting any flows.
The Torus Key Infrastructure is the underlying layer that powers OpenLogin and is a model of threshold key management that retains end-user autonomy without sacrificing user experience. The model manages Shamir Secret Shares (SSS) using the user’s devices, private inputs, and wallet service providers. The user’s private key is split into multiple factors, and these split factors are used to reconstruct the original secret key.
Similar to 2FA systems, as long as the user has access to 2 out of 3 of their factors, they will be able to retrieve their private key.
- User Device Factor: Implementation is device and system-specific. For example, a user accessing OpenLogin through their mobile device would store this factor on their device storage secured via biometrics.
- Social Login Factor: This factor is kept and managed by a login provider via their own authentication. With Torus, this factor is further split via a distributed key generation protocol and kept on large ecosystem stakeholders https://docs.tor.us/how-torus-works/overview to secure your factor further, retrievable via OAuth logins.
Further decentralizing the social login, this corresponding “share” is split into sub-shares
3. Recovery Factor: This is based on user input (eg. password, security questions, hardware device, etc.).
As long as the user has any 2 of their factors, they would be able to gain access to their wallet.
This setup provides several benefits for users:
- Improvements to key recovery — In the event when one of the factors is lost, (e.g. device loss), users can still retain access to their keys, and revoke access rights for the lost factors.
- Non-custodial — The service provider cannot access the user’s private key since they only have one factor. They also cannot censor users and prevent them from gaining access to their keys since the user holds their own recovery factor. Users can also choose to migrate to other service providers.
- Progressive security — TKI gives users flexibility in access control based on their desired level of security. Increasing the threshold of factors required for the reconstruction of the key would in turn increase the security of their key (e.g. configuring access to require 3 out of 4 factors).
Integrating OpenLogin on Avalanche is quick and easy, taking about 10 minutes of developer time. To get started, developers can follow the simple guide with code snippets and have it up and running within minutes.
Developers looking for an example code project can check out TORUS’ GitHub repo.
Users keen on trying out OpenLogin can do so at https://openlogin.com.