zkLogin is a straightforward solution to a persistent problem in blockchain: new user onboarding friction due to wallet complexity. By using cutting-edge cryptography and technology, zkLogin is as elegant as it is intricate. This article delves into the mechanics of zkLogin, covers security aspects for users and builders, and explains how Sui’s design facilitates this innovative OAuth login process.

Let’s dive in!

How zkLogin Works

With zkLogin a unique Sui address is created for each OAuth credential + app combination. A single OAuth credential can be used to manage independent addresses associated with an unlimited number of apps. For example, a single Google account connected to two different decentralized exchange apps will have two distinct Sui addresses—one for each app.

For a typical blockchain address, a persistent public-private key pair is associated with the address at the time of creation and the address identifier is derived from the public key. With zkLogin, addresses are associated with temporary key pairs which must be regenerated regularly through an OAuth login flow. By design, Sui addresses are able to remain fixed while the associated key pair can be changed. This is possible because zkLogin addresses are derived from a unique identifier obtained from the OAuth provider's returned payload called the “key claim”, rather than a public key. 

The process for zkLogin is six sequential steps:

Step 1: Generate ephemeral keys

When a user opens the app, it generates a temporary, or ephemeral, keypair for the user. This keypair is given an expiration period which determines the frequency of required log-ins. 

Step 2: Generate a JSON Web Token (JWT)

The app prompts the user to authenticate themselves through an OAuth provider sign-in, yielding a JSON Web Token (JWT)—a digitally signed data payload from the provider. This JWT incorporates a nonce field, which, in the context of zkLogin, encompasses the public key alongside an expiration period. Embedded in the JWT is the key claim which is used to generate the Sui address later.

Step 3: Request the user’s unique salt

The salt is an arbitrary string of numbers that is used in combination with the JWT and ephemeral keypair to associate the OAuth credentials with the Sui address. The path taken in this step is app dependent as there are different design options for builders. The zkLogin docs outline multiple options for salt management, each with their own tradeoffs.

One approach is an SSO-style salt management option that employs a salt service to store and provide the salt as needed. With this path, the app sends the JWT token to a salt service which returns the unique user salt upon validation of the JWT token. Another approach to salt management requires the user to set their salt when they log in for the first time and to manage it themselves, treating it as a password or pin.

Step 4: Generate a zk proof

Armed with the JWT token, salt, and public key, the process proceeds to request a zero-knowledge (zk) proof from a zk proving service. This crucial step rigorously scrutinizes the accuracy of the request by ensuring: 1) the nonce is defined correctly and includes the public key, 2) the key claim provided is consistent with the JWT, 3) the address is consistent with the key claim and user salt, and 4) the OAuth providers signature is correct. If any element fails to conform to expectations, the whole step will fail.

Step 5: Identify the user's Sui address and construct transaction

The application then identifies the user’s Sui address based on the user salt and key claim extracted from the JWT. A transaction is endorsed using the private key bundled with the ephemeral signature, zk proof, and supplementary inputs from the JWT before being forwarded to Sui. 

Step 6: Validate transaction

Once on the blockchain, Sui validators meticulously scrutinize both the zk proof and the ephemeral signature for authentication. In the blink of an eye, the transaction is officially logged in Sui, seamlessly concluding the process.

zkLogin natively facilitates a simple login process using OAuth credentials.

Security Considerations

Just as with any other “sign-in with X” functionality, users need to ensure the security of the account they use for logging in. If for any reason the user is unable to login with their OAuth credentials, they will not be able to access Sui addresses associated with that credential. Those who forget their password can resort to the standard recovery procedure provided by the OAuth service to restore access. 

It is strongly advised that all OAuth accounts used in zkLogin operations incorporate two-factor authentication (2FA) to increase the security of both their OAuth provider account and their associated Sui addresses. Application builders should also encourage their users to implement security best practices, such as secure passwords and 2FA. It’s important to note that even if the OAuth account is compromised, for the hacker to access a Sui address via zkLogin, they must also acquire the user salt.

App builders should prioritize safeguarding and limiting exposure of the salt value. This value serves as the linchpin connecting users' Web2 and Web3 credentials, and its submission to the zk prover is pivotal. Therefore, it is highly advisable to host the zk proving service within the application's backend, effectively curbing any potential third-party access to the salt. Builders retain the option to independently develop their own zk prover by leveraging the readily available common reference string.

For more information on prover and salt management read the zkLogin best practices and business considerations for builders.

Sui is uniquely positioned for zkLogin

Sui’s cryptographic agility and object-oriented design enables a seamless OAuth login integration through zkLogin. Unlike most blockchains that inherently support only one cryptographic authentication method, Sui distinguishes itself by allowing the integration of various cryptographic schemes directly. This ability eliminates the need for users to incur additional gas costs for transaction execution using out-of-protocol cryptography. With Sui, the introduction of new native cryptographic authentication methods maintains compatibility with existing systems, ensuring users aren't disadvantaged for opting different cryptographic approaches.

Conventional Web3 OAuth login solutions rely on smart contracts for JWT validation, necessitating trust in the accuracy of oracle data posting. Sui revolutionizes this process by representing JSON web keys (JWTs) as Sui objects, consolidating validation. With zkLogin, Sui validators take on the role of oracles, ensuring adherence to the predefined rules for JWT verification. This streamlined approach enhances security and reliability in the authentication process.

Looking forward

As zkLogin takes its inaugural steps on mainnet, we anticipate an exciting future with the incorporation of additional OAuth providers and enhanced functionality. zkLogin marks a significant milestone for the Sui ecosystem, yet the real thrill lies ahead as builders take the reins to integrate zkLogin into their apps. The vast potential of implementing this primitive will inevitably trigger an evolution for the ecosystem. The journey has only just begun and possibilities are boundless.

For more details on how to integrate zkLogin into your app, visit the zkLogin documentation.