Summary: zkLogin is best understood not as a generic social-login wallet or a conventional custodial onboarding flow, but as a Sui-native authentication and address-derivation primitive that combines OpenID Connect tokens, ephemeral keys, user-specific salt, and zero-knowledge proofs. Its core move is to let a user authenticate with an existing OAuth account while deriving and using a Sui address that is not publicly linkable to that OAuth identifier. The reusable mechanism insight is that zkLogin separates OpenID-issued identity claims, validator-agreed JWK verification, ephemeral session keys, user-salt custody, zero-knowledge proving, optional identity revelation, and Sui-native transaction features like sponsored transactions and multisig into a comparison-ready wallet/auth stack.
What it does:
Lets users send Sui transactions using familiar OAuth login flows instead of mnemonic or hardware-wallet onboarding
Derives a Sui address from OpenID claims plus a user-specific salt while hiding the direct OAuth-identity linkage onchain
Uses an ephemeral key pair and JWT nonce commitment to authorize a short-lived signing session
Requires a zero-knowledge proof that the signer controls a valid OAuth credential corresponding to the hidden identity inputs
Supports optional identity disclosure when builders or users want a verifiable onchain identity layer rather than only unlinkable accounts
Integrates natively with Sui features such as sponsored transactions and multisig rather than living only as an offchain middleware layer
Key claims:
The strongest analytical split in the docs is that zkLogin is simultaneously an onboarding primitive and a privacy system. It does not just let users log in with OAuth; it uses zero-knowledge proofs and salt-based address derivation to keep the OAuth identifier hidden from public chain observers.
The Sui docs explicitly frame zkLogin as two-factor authentication: a recent OAuth credential is insufficient on its own because the address derivation and signing flow also depend on a user salt that is not controlled by the OAuth provider.
The primary materials are also unusually clear about operational control surfaces. A real zkLogin deployment usually involves a frontend, a salt backup service, and a proving service, even if the protocol goal is to avoid introducing new signing authorities.
The validator-agreed JWK path matters. Sui documents describe provider JWKs as an oracle whose correctness is maintained by validator quorum rather than by a single application operator, which makes issuer-key ingestion part of the protocol’s trust surface rather than just a wallet implementation detail.
The example flow is useful because it exposes the practical state layout: ephemeral key and randomness in session storage, salt and expiry data in local storage, and external proof fetching from a Mysten-maintained proving service.
zkLogin’s Sui-specificity is analytically important. The docs emphasize that its native deployment on Sui enables cleaner composition with sponsored transactions and multisig than many chain-agnostic social-login abstractions can offer.
zkLogin belongs in the corpus because it gives the wallet/auth cluster a strong comparison point for privacy-preserving OIDC-based blockchain authentication, especially around the split between identity provider, proving service, salt custody, validator-side key acceptance, and optional identity revelation.
Whitepaper: The canonical paper is zkLogin: Privacy-Preserving Blockchain Authentication with Existing Credentials (arXiv:2401.11735 / CCS 2024). Supporting primary materials are collected in ../whitepapers/zklogin-primary-sources-2026-05-13.md.
Use eip-4361 and caip-122 as the clean contrast for wallet-signed login. zkLogin derives a Sui account from OIDC instead of asking an existing wallet to sign a session assertion.
Use zk-email when the point is privacy-preserving auth from familiar web2 identity rails rather than wallet-native signatures.