DOCSEARCHbyAlgolia
Submit Docs

ZeroAuth Documentation

website·Indexed 31 days ago

https://zeroauth.dev/

A passwordless authentication system where users enroll credentials locally on their own devices, utilizing cryptographic commitments to ensure that no secrets are stored in a central vault.

Tokens
464
Snippets
1
Records
3
Agent score
3%

What's inside ZeroAuth

  1. Enroll a user locally on-device

    During the enrollment process, the user creates a credential directly on their own device. To maintain security, only a cryptographic commitment (a hash of the secret) is generated and stored/registered; the actual credential secret never leaves the user's device.
    // On the user's device
const secret      = generateCredential();
const commitment  = poseidonHash(secret);
register({ commitment });

  2. Understand ZeroAuth's Zero-Knowledge Proof (ZKP) authentication flow

    ZeroAuth implements an authentication flow where no secrets or credentials ever touch the server. The process follows these steps:

    1. Device Authentication: The user authenticates locally on their device (e.g., via biometric scan).
    2. Proof Generation: A ZK-SNARK circuit generates a proof on-device using private input (such as a biometric hash). This private input never leaves the device.
    3. Server Verification: The server receives only the proof ($\pi$) and verifies it against public input. If valid, access is granted to Enterprise SSO providers (e.g., Salesforce, Slack, GitHub, AWS) without transmitting credentials.
    4. Ephemeral Session: The server creates a session (e.g., in Redis) containing only an ephemeral token and session ID, with no link to the user's private biometric data.

  3. ZeroAuth data storage and security model

    ZeroAuth is designed so that a full database or server breach exposes zero exploitable credentials. The storage model is as follows:

    • PostgreSQL: No users or credentials tables exist by design. Only non-sensitive business data (e.g., leads) is stored.
    • Redis: Stores only ephemeral session tokens; biometric data is explicitly undefined/not stored.
    • Blockchain (DIDRegistry): Stores only irreversible Poseidon commitments or SHA-256 hashes of biometric IDs. Raw biometrics and private keys are never stored on-chain.
    • Client Device: The only location where private keys and raw biometric hashes reside.