zkLogin Best Practices and Business Considerations for Builders
Key issues, including salt management, to review before integrating zkLogin into your app
With zkLogin going live on Sui Mainnet this week, builders can begin offering their users frictionless account creation for their apps. As with any new tech integration, builders have many important topics to consider to mitigate risks and optimize for success.
This blog outlines some of those considerations and highlights explicit guidance available in the zkLogin docs.
zkLogin offers self-custody addresses only
Most Web3 solutions with user-friendly onboarding come from custodial providers. These providers manage the private key for the user and offer familiar recovery paths should a user forget their password. While this solution works for the enterprises willing to satisfy the regulatory obligations required to custody assets, many builders don’t have the time and budget to undergo that process.
That’s where zkLogin comes in. The primitive’s self-custody path reduces the regulatory burden and reduces the time to market for simple sign-on. The challenge however, is that each builder must consider how comfortable their users are with self-custody, and if zkLogin is right for all, some, or none of their users. This understanding will help determine what other account creation and key management systems a builder may want to incorporate alongside zkLogin, if any.
Web credentials should be kept off-chain
zkLogin uses the best cryptographic approaches available today to ensure an on-chain address cannot be directly linked to a web credential, including by the credential provider. For example, if you use your Google account to generate a Sui address, Google is never notified and cannot link the address to you. This design is intentional and critically important, not least because of global privacy laws (such as GDPR in Europe and CCA in the United States) which credential providers must abide by. App builders will want to familiarize themselves with the many privacy laws that govern, among other things, what user information can be shared and with whom, as well as their obligations for storing, securing, and deleting user data.
When implementing zkLogin, builders will often have the choice to use a sub (a unique alpha-numerical identifier for a user) or the actual web credential (e.g., an email address) to generate the user’s on-chain address. Separating the issues of on-chain account derivation from that of identity or discovery (e.g., more accessible ways for users to interact with each other) is recommended. Users may not desire, expect, or benefit from having their information irreversibly placed on-chain within their on-chain address. One option would be to use a name service (which is like a domain url) as the identity layer for the user to help mitigate this risk.
Prover and salt management are privacy-sensitive
Sui docs offer a detailed outline of how zkLogin works to generate an address. To summarize, a user will log in with their OAuth web account to produce a JSON web token(JWT). The application will then supply the JWT and a salt (a common cryptographic term for random data) to a zero knowledge (zk) proof generator, and the proof is then included as part of a transaction on Sui. This flow ensures that the web account information is never visible on-chain.
As a builder, you have a choice to run your own prover and salt management solution or to use a third party. Zk-savvy builders can even choose to build their own prover from scratch using the publicly available common reference string.
Operating a prover and managing salts is a privacy-sensitive task. Any entity performing these services will, in principle, be able to link web credentials to Sui addresses, even though this information is not visible on-chain. If you are building a privacy-sensitive application (e.g., one where users will likely store high-value assets or amounts), it is worth considering running your own prover and doing your own salt management rather than relying on a third party.
When using a third-party service, make sure that you run through appropriate governance (according to your own business policies) for your product, usage of the third-party services, as well as abide by applicable laws regarding disclosure to users.
Salt management tradeoffs
Choosing a scheme for salt management is one of the most important decisions a zkLogin builder must make. The zkLogin docs outline several options for salt management, each with its own convenience, security, and recoverability tradeoffs. At a high level, there are two approaches: SSO-style and password-style.
Significant tensions exist for builders between letting users in and preventing bad actors from accessing assets. Every builder will need to find the right place for their app on the spectrum between ease and security. Whatever route is adopted, builders using zkLogin should always ensure all applicable disclosures are made to users.
Let’s build a better internet for all
It’s due time for blockchains to deliver breakthrough experiences for everyone, and builders on Sui are ready to serve a broad audience. There are approximately 100 million blockchain addresses versus 4+ billion web accounts. zkLogin is a crucial step in bringing blockchain to a mainstream audience. This feature, when implemented in a well-considered manner, will ensure that Sui offers the best experiences for the next billion users.
