zkLogin

• Name: zkLogin
• URL: https://docs.sui.io/sui-stack/zklogin-integration/zklogin
• Category: privacy-preserving blockchain authentication / walletless onboarding primitive / OIDC-bound account infrastructure
• Tags: sui-ecosystem
• Summary: zkLogin is a Sui-native authentication and address-derivation primitive, not a generic social-login wallet. The important split is between 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 such as sponsored transactions and multisig.
• 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.
• Sources:
  • https://docs.sui.io/sui-stack/zklogin-integration/zklogin
  • https://docs.sui.io/sui-stack/zklogin-integration/zklogin-example
  • https://www.sui.io/zklogin
  • https://arxiv.org/abs/2401.11735

Internal linkages

• Clean contrast for wallet-signed login: eip-4361. 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.

Control surface

• The leverage sits in salt custody, proving-service operation, validator acceptance of issuer JWKs, and app defaults around sponsorship, account recovery, and identity revelation.

• So the right read is a Sui auth primitive whose practical trust surface still includes offchain proving and storage operators, not just log in with Google for crypto.

• Last reviewed: 2026-06-17 UTC