How zkLogin Works on Sui @SuiNetwork's zkLogin feature lets users access a Sui address through a familiar OAuth login, such as a Google account, without ever generating a seed phrase. Accordi
@SuiNetwork's zkLogin feature lets users access a Sui address through a familiar OAuth login, such as a Google account, without ever generating a seed phrase. According to the official Sui documentation, the address is derived from four inputs: the user's identifier (sub), the provider (iss), the application client ID (aud), and a per-user salt. Feed in the same four values and you always get the same address.
The mechanism that makes this secure without exposing any credentials on-chain is a Groth16 zero-knowledge proof. The Sui docs explain that "a proving service takes the JWT, the ephemeral public key, a per-user salt, and the max epoch, and produces a zero-knowledge proof" that attests the user holds a valid OAuth credential for that address, without revealing the JWT on-chain. Groth16 was chosen because, as noted in a published research paper on zkLogin, it offers mature tooling and compact proof sizes.
Sessions are time-limited by design. Each login generates a short-lived ephemeral key pair. When that session expires, the user simply logs in again to generate a new key pair and proof, while the underlying Sui address remains unchanged.
The per-user salt is the critical variable that separates the OAuth identity from the on-chain address, providing a privacy layer so that no one can link a Sui address back to a Google account just by inspecting chain data. But the salt also introduces a meaningful custody decision: it has to be stored somewhere the OAuth provider does not control.
The Sui documentation frames the wallet as effectively "a 2-of-2 multisig where the 2 credentials are your OAuth credentials and the salt." That framing makes the risk clear. Losing access to a Google account is recoverable through Google's own account recovery flow. Losing the salt is not. If the salt is gone, the address is permanently inaccessible, regardless of whether the Google account is intact.
Developers building on zkLogin therefore face a genuine design decision over how and where to store the salt, balancing convenience against the risk of permanent loss. Options range from a dedicated salt service to self-managed storage, each carrying its own security assumptions.
For users new to on-chain applications, zkLogin removes the most common point of friction: the seed phrase. But it shifts rather than eliminates the custody responsibility, replacing one critical secret with another.
Sources:Sui Documentation: What is zkLogin?Sui Documentation: zkLogin Technical ReferencezkLogin: Privacy-Preserving Blockchain Authentication with Existing Credentials (arXiv)
