Skip to main content
Passwords get forgotten. Security questions get phished. Account recovery is one of the highest-friction, highest-risk flows in any application. FaceSign replaces “mother’s maiden name” with real-time face recognition — matching the user against their enrolled biometric and confirming their identity through an AI-powered conversation.
Requires enrolled faces — The RECOGNITION node matches the user against faces already stored in your FaceSign database. You need to enroll users during onboarding or account setup before they can use face-based recovery. See Verification Patterns for enrollment flows.

How it works

  1. The user clicks “Forgot password” or “Can’t access my account” in your application.
  2. Your backend creates a FaceSign session with recognition (1:N face matching), liveness detection, and a conversation node for knowledge-based verification.
  3. You embed clientSecret.url as an iframe src inside your recovery page — the verification runs inline on your domain, keeping the user in your app and branding. Redirecting the user to the hosted URL is the fallback when an iframe can’t be used (e.g., strict parent-frame CSP, native mobile wrappers without a webview).
  4. FaceSign matches the user’s face against your enrolled database and asks them to confirm account details.
  5. Your webhook handler receives the result — if the face matches a known user, you grant access and let them reset their credentials.

The recognition branching pattern

The proven pattern for flows that use facial recognition branches recognized users and new users into separate paths, each with its own liveness check and conversation node. This avoids putting conditional logic in a single prompt — the most common cause of broken flows.
Recognition branching
Always route every liveness and recognition outcome forward to a conversation node. Do not route any outcome to end or an error state. The video AI analysis handles deepfake scoring separately, out of band.

Build the flow

1

Define the verification flow

Create a session with recognition to match the user against enrolled faces, liveness detection to prevent photo/video replay attacks, and a conversation node to confirm account details.
Account Recovery Flow
2

Create the session from your backend

When a user initiates account recovery, call the FaceSign API.
services/account-recovery.js
3

Handle the webhook

When the session completes, check the recognition result and grant or deny access.
api/webhooks/facesign.js

Recognition outcomes

The RECOGNITION node returns one of three outcomes. Your recovery logic should handle each one:
Never skip liveness after recognition. A recognition match alone does not prove the live person is present — an attacker could hold up a photo of the enrolled user. Always chain RECOGNITION with LIVENESS_DETECTION.

Strengthening the flow

You can add additional verification steps depending on your security requirements:

Troubleshooting


Next Steps

Wire Transfer Authorization

Add step-up verification for high-value financial transactions

Step-Up from Anomaly Detection

Trigger verification when your fraud system detects suspicious activity

Verification Patterns

Explore more flow patterns including enrollment and KYC