Zero-knowledge auth · Live

Forget OAuth.
This is auth for the AI age.

AuthenSee authenticates your users with zero-knowledge proofs instead of passwords. Mint a session, hand off to a hosted flow, exchange a one-time code. You integrate it like a payment provider — and store nothing phishable.

Open provider dashboard →See the flow
The whole client integrationapp.js
$ npm i @rebellion-systems/authensee-embed

import { open }
  from '@rebellion-systems/authensee-embed';

open({
  flowUrl: async () => {
    const res = await fetch('/api/authensee/session',
      { method: 'POST' });
    return (await res.json()).hostedUrl;
  },
  onComplete: ({ authResultCode }) => {
    // exchange server-side, get a JWT
    fetch('/api/authensee/complete', { … });
  },
});
The integration

Three calls.
Like a payment provider.

The passkey ceremony and proof generation run on AuthenSee's origin, in a popup on the user's device. Your code never touches a secret — it moves session handles and one-time codes.

01Server

Mint a session

POST /v1/sessions with your secret key. A session scopes one enrollment or login and names your callback.

hostedUrl
02Popup

User proves

The drop-in opens the hosted flow on AuthenSee’s origin. Passkey ceremony + ZK proof run on-device.

authResultCode
03Server

Exchange the code

Swap the single-use code for a signed auth result. Verify the EdDSA JWT against the public JWKS.

providerSubject + token
Server side — mint, then exchangecurl · or @rebellion-systems/authensee-sdk
# 1 · a session scopes one login
curl -X POST api.authensee.com/v1/sessions \
  -H "x-api-key: sk_live_…" \
  -d '{ "scope": "full",
       "externalUserId": "user_12345",
       "callbackUrl": "…/callback" }'

→ hostedUrl // hand this to the browser
# 3 · exchange the one-time code
curl -X POST …/v1/auth-results/exchange \
  -H "x-api-key: sk_live_…" \
  -d '{ "authResultCode": "ar_bxvS6d…" }'

→ status: "authenticated"
→ providerSubject // stable user id
→ token // EdDSA JWT, verify via JWKS
Zero-knowledge, concretely

What each party actually sees.

Proofs are generated on the user's device — WASM in the browser, native on mobile. Everything past the device boundary is opaque by construction.

Stays on device

The user's device

  • Passkey private key
  • Image points the user chose
  • Motion-gesture template
  • Proof generation (WASM / native)
→
Server-blind

AuthenSee's server

commitment 0x9c2e·8b7d·████
nullifier 0x4e0a·a3f1·████ · spent
proof verifies ✓

Verifies proofs without ever seeing answers, gestures, or keys.

→
One thing

Your backend

status: "authenticated"
factorsVerified:
  ["image_points","passkey"]
token: eyJhbGciOiJFZERTQSI…

A signed result. No credential to store, leak, or rotate.

Properties

Guarantees you don't
have to build yourself.

✦

No passwords

Nothing to phish, stuff, or rotate — authentication is a proof of knowledge, not a stored credential.

✦

Server-blind factors

The AuthenSee server verifies proofs without ever seeing answers, gestures, or keys.

✦

Exposure-resilient

A full database dump reveals only opaque commitments and spent nullifiers — nothing exploitable.

✦

Replay-proof

Every proof carries a single-use nullifier; a captured proof can never be reused.

✦

Enroll once, use everywhere

Users reuse the same persona across every AuthenSee-integrated app. No re-onboarding.

✦

Factor-agnostic

passkey_and_image_points, passkey_only, or passkey_and_behavior — switch policy without forcing re-enrollment.

✦ Self-serve · Test keys free

Ship it this afternoon.

Create a provider, copy your sk_test key, and run the quickstart. Five steps, one dependency, no credential storage.

Open provider dashboard →API reference