Authentication Modes: What the Face Is Compared Against

A liveness check proves a live human is present. Authentication comes from what the live face is compared against. OIDC Web supports three modes. The first two are selected purely by the standard OIDC login_hint parameter; the third adds a reference photo pre-loaded through the user-management API:

Mode	You send	What happens
Liveness only	No login_hint (or login_hint=face:any)	The user passes a liveness check. Any real, live face passes. The check proves a human is present; it identifies no one.
Hosted biometric profile	login_hint=<your stable user identifier> (an email address or opaque ID)	The first time an identifier is seen, the live face is enrolled as that user's biometric profile on iProov's servers. Every subsequent login with the same identifier is a 1:1 verification against that profile: only the same person passes.
Reference-photo verification	A login_hint identifier, with the profile pre-created from your photo via the user-management API	You pre-create the user's biometric profile from a trusted reference photo — an ID-document portrait, an HR photo. Every login by that identifier, including the first, is then a 1:1 match against your reference photo.

Two properties of the hosted-profile mode are worth understanding up front:

• The identifier is yours. OIDC Web never asks the user who they are. Your application asserts the identifier in login_hint, and the profile it maps to is private to your organization. The same email used by two different customers maps to two unrelated profiles.
• Enrollment is automatic on first use — a pattern known as "trust on first use". Some integrations need even the first login verified against a known face. For those, pre-create the profile from a trusted photo using the user-management API. Then even the very first login is a 1:1 verification.

A note on sub. The ID token's subject identifier is unique per authentication session — never a stable cross-login identifier. Correlate logins through the identifier you supplied in login_hint, which is echoed back in the token claims (see What Your Application Receives).