Skip to main content
Version: v2.0 (latest)

First-Factor and Second-Factor Authentication

The authentication modes support two distinct ways of deploying OIDC Web: as a second factor on top of an existing login, or as the login itself.

As a Second Factor (Workforce MFA)​

Second-factor deployment is the flagship use, productized as iProov Workforce MFA. Your application (typically an IAM platform) has already authenticated the user with a first factor. The first factor might be a password, a single sign-on (SSO) session, or a passkey.

The platform sends the user to OIDC Web with login_hint set to its own stable identifier for that user. OIDC Web verifies the user's live face against their hosted biometric profile. The result comes back as a signed OIDC response.

Why a face beats a one-time code as the second factor:

  • Phishing-resistant. There is no code to read out to an attacker, and no push notification to approve by reflex. The factor is the user's live face.
  • Inherence, not possession. A stolen phone or SIM swap does not defeat it. An attacker would have to pass a liveness check as the victim.
  • Simple for users. A brief face scan suffices — no app installation, no token hardware.

OIDC Web integrates with Microsoft Entra ID as an External Authentication Method, and with OneLogin and Ping. Beyond login multi-factor authentication (MFA), the same mechanism covers:

  • Step-up authentication — re-verify the user's face before a sensitive action such as a large payment, a data export, or an admin operation.
  • Account recovery — a user who lost their password or other second factor proves they are still the same human. A face verification against their profile replaces insecure security questions and helpdesk calls.

As a First Factor​

OIDC Web can also be the login. Your application sends the identifier the user typed (or a remembered one) as login_hint. The face verification is then the primary authentication. Two configurations are available:

  • Trust on first use — the first login under an identifier enrolls the live face automatically, and every later login must match it. Choose this when the identifier's first use happens in a controlled context, such as following an invitation link you issued.
  • Pre-provisioned profiles — you create each user's profile from a trusted reference photo via the user-management API before their first login. The photo can be an ID-document portrait or an HR photo. Every login is then a true 1:1 verification, including the very first.

A pure liveness gate (no login_hint) is also available as a building block. The gate authenticates no one, but proves a live human is present. Use it against bots, scripted signups, and synthetic traffic.