Suinetwork Suinetwork zkLogin: when OAuth login fits Sui apps
Updated:Sui's zkLogin is a protocol-level primitive that lets users authorize transactions through a supported OAuth sign-in without managing a seed phrase or a persistent private key. It fits apps onboarding people without wallets, with salt retention and session renewal as important integration requirements. Apps can also offer existing-wallet connections through dApp Kit.
App needs and documented options
| App requirement | Documented option |
|---|---|
| Onboard people without wallets | zkLogin with Enoki for managed salt and sponsored transactions. |
| Serve newcomers and existing wallet users | zkLogin alongside traditional wallet connections through dApp Kit. |
| Connect users who already have Sui wallets | Traditional wallet connection through dApp Kit; zkLogin is optional. |
| Control proving and salt management | Self-hosted zkLogin integration. |
| Provide a backend service or agent identity | zkLogin with a service-owned OAuth credential. |
Address continuity and session limits
A zkLogin address derives from the provider's user identifier (
sub
), the provider (
iss
), the application's OAuth client ID (
aud
), and the per-user salt (
user_salt
). The same inputs produce the same address. Changing the provider or application client ID produces a different address.
The signing session has a separate lifetime. The
maxEpoch
parameter limits how long an ephemeral key pair can authorize transactions; the address itself doesn't expire. The ephemeral private key signs transactions, and validators verify its signature together with the zero-knowledge proof.
Both managed and self-hosted integrations depend on retaining the correct salt. If that salt is irretrievably lost, a valid OAuth login can't restore access to the corresponding zkLogin address. Salt persistence, backup, and recovery therefore belong in the integration decision.
Hypothetical example: Session renewal and a client ID change
Suppose a hypothetical Sui app uses Google sign-in and requires a user's address to stay unchanged after a signing session expires. In this example, the user's Google identity, the app's OAuth client ID, and the per-user salt remain fixed.
Session renewal uses a new ephemeral key pair and proof while preserving those address inputs, so the derived address stays the same.
Now suppose a hypothetical configuration change replaces the app's OAuth client ID while the Google identity and salt remain unchanged. Changing
aud
yields a different derived address. That configuration doesn't meet the same-address requirement, even though the person still signs in with the same Google account.
Provider support and infrastructure control
Provider support depends on the target network. Sui's zkLogin provider matrix lists Google, Apple, Facebook, and Twitch for Mainnet, Testnet, and Devnet. Slack, Kakao, and Microsoft are listed only for Devnet. AWS tenant support requires enablement for the particular tenant. An app still needs to configure its chosen OAuth provider.
A fresh signing session requires OAuth authentication and generation of a valid proof. Self-hosting gives the app team control over proving and salt management. A managed-salt option delegates salt management to a service, while future access still requires the correct salt and a valid OAuth credential.
Privacy and authorization boundaries
The zero-knowledge proof establishes possession of a valid OAuth credential without revealing its JWT onchain. zkLogin is designed to avoid publicly linking that OAuth identity to the Sui address. An app that needs the user's email must request the
email
scope and read the JWT claims during OAuth sign-in; it can't recover the email from the zkLogin address or proof.
The OAuth provider alone can't transact on the user's behalf. The OAuth credential and per-user salt are both required factors, alongside the session signing mechanism. Familiar sign-in therefore still depends on the integration's handling of those components.
Gas sponsorship is an additional choice
zkLogin can be combined with sponsored transactions, and Enoki is a documented consumer-app option for managed salt and sponsorship. OAuth authentication alone doesn't remove Sui's computation and storage charges or establish that a particular app will sponsor them.