AuthenSeeDocs

AuthenSee Documentation

Zero-knowledge proof-based authentication. No passwords, no shared secrets. User secrets never leave the device.

AuthenSee

AuthenSee is a zero-knowledge proof-based authentication platform. Users enroll their authentication factors — security questions, passkeys, image recognition, and more — once and reuse them across every integrated provider. No passwords are stored anywhere. User secrets never leave the device.

How it works

  1. Enrollment -- The user completes authentication factors on their device (e.g., answers security questions, registers a passkey, identifies images). Factor responses are hashed with Poseidon2, assembled into a Merkle tree, and only the Merkle root (a single cryptographic commitment) is sent to the server. Raw responses are discarded from memory immediately.

  2. Authentication -- When the user needs to prove their identity, they re-complete their factors on-device. The SDK generates a zero-knowledge proof that they provided correct responses -- without revealing the responses themselves. The server verifies the proof and issues a JWT.

  3. Verification -- The server checks the ZK proof against the stored Merkle root. It never sees the responses, the individual hashes, or the tree structure. Even a full database breach reveals nothing exploitable.

Supported factor types

FactorType IDDescription
Security questionsEPISODIC_TEXT (1)Free-text answers to memorable questions
Image recognitionRECOGNITION (2)Select the correct image from a set
Pattern drawingDOODLE (3)Draw a memorable 16×16 pattern
Symbol sequenceSEQUENCE (4)Arrange symbols in a remembered order
Map routeMAP_ROUTE (8)Select 4 memorable locations on a map
PasskeypasskeyFIDO2/WebAuthn hardware-backed key

All factor types produce the same output: a Poseidon2 hash that becomes a leaf in the Merkle tree. The ZK circuit verifies answers without knowing which factor type was used.

Quick start

1. Create a session token (server-side)

Session tokens are created on your backend using your secret key. They scope SDK operations to a specific provider session.

curl -X POST https://api.authensee.com/v1/sessions \
  -H "Authorization: Bearer sk_live_your_secret_key" \
  -H "Content-Type: application/json" \
  -d '{ "externalUserId": "user_12345" }'

Response:

{
  "sessionId": "sess_abc123def456",
  "flowCode": "flow_abc123def456",
  "hostedUrl": "https://auth.authensee.com/flow/flow_abc123def456",
  "expiresAt": "2026-04-09T12:00:00Z"
}

2. Install the provider SDK and embed

npm install @rebellion-systems/authensee-sdk @rebellion-systems/authensee-embed

3. Launch the hosted flow

Use @rebellion-systems/authensee-sdk only on your backend with your sk_ secret key. Use @rebellion-systems/authensee-embed in the browser to open the hosted flow and relay the one-time result code back to your backend.

import { createAuthenSeeSdk } from '@rebellion-systems/authensee-sdk';
 
const authensee = createAuthenSeeSdk({ serverUrl, apiKey: providerSecretKey });
 
const session = await authensee.createSession({
  scope: 'full',
  externalUserId: 'user_12345',
  callbackUrl: 'https://provider.example.com/authensee/callback',
});
 
const result = await authensee.exchangeAuthResult(authResultCode);
console.log(result.providerSubject, result.factorsVerified);

Key properties

PropertyDescription
Zero-knowledgeThe server verifies proofs without learning any user secrets
No passwordsAuthentication is based on ZK proofs of knowledge, not stored credentials
Exposure-resilientA full database dump reveals only Merkle roots and nullifiers -- nothing exploitable
Replay-proofDeterministic nullifiers ensure each proof can only be used once
Cross-providerUsers enroll once and authenticate across all integrated providers
On-device provingZK proofs are generated natively on the user's device using barretenberg

Next steps


Built by Rebellion Systems.

On this page