Login methods

The three ways a user proves identity in a SenseCrypt sign-in — Simple QR in the Authenticator app, a FIDO2/WebAuthn passkey, and the enterprise Simple Webcam — and how to choose between them. Your OIDC/SAML integration is identical for all three.

Every SenseCrypt sign-in proves the person with a live face check and liveness detection. The two phone-based methods also prove the device with a key held on the user's phone. What changes between login methods is where the face is captured and what the possession factor is, if there is one. There are three:

Simple QR — the face check runs in the SenseCrypt Authenticator app on the user's phone.
Passkeys (FIDO2/WebAuthn) — the possession factor is a real WebAuthn passkey, and the sign-in is bound to your origin (phishing-resistant).
Simple Webcam — an enterprise-only option where a webcam face scan on a trusted customer network takes the place of the phone.

The method is a per-application setting, and it is invisible to your integration: your app runs the same standard OIDC authorize-and-token exchange (or SAML AuthnRequest/assertion) no matter which method a user goes through. This page explains what each method is, when to choose it, and the security trade-offs. For the underlying model — biometric blindness, per-sign-in rotation, the four parties in a sign-in — read How SenseCrypt works first.

Choosing a method

Method	Where the face is captured	Possession factor	Phishing-resistant	Availability
Simple QR	The user's phone (Authenticator app)	The phone's hardware-bound device key	No — the QR is a bearer link, not origin-bound	Default; self-serve
Passkeys	The user's phone	A FIDO2/WebAuthn passkey (ES256)	Yes — WebAuthn binds each assertion to your sign-in origin	Self-serve (`login_method: passkeys`)
Simple Webcam	A webcam on a trusted customer network	None — there is no phone, so the face check and its liveness detection carry the sign-in	No — not origin-bound	Enterprise customers only; not on the hosted service

A short way to decide: Simple QR is the broadest-reach default and the lowest-friction flow for users who have the Authenticator app. Passkeys is the choice when origin-bound, phishing-resistant login matters. Simple Webcam is for controlled-network deployments where users sign in at a desktop or kiosk without a phone.

Selecting the method for an application

The method is chosen per application with the login_method field on the OIDC client (or SAML service provider). It takes one of three values:

simple_qr — Simple QR. This is the default for newly created apps.
passkeys — the FIDO2/WebAuthn method.
webcam — Simple Webcam. Only an enterprise deployment licensed for it accepts this value; see its section below.

Set it on the application's detail page in the admin console, or through the Admin API when you create or update the app. The value is stamped onto each sign-in session when the browser hits /authorize, and is fixed for the life of that session — so changing an app's method affects only new sign-ins, never one already in flight.

Switching a live app between Simple QR and Passkeys does not strand enrolled users. Enrollment normally mints a passkey regardless of the app's current method, so most users already hold one; and any user with the Authenticator app can always complete Simple QR. You can move an app to passkeys without a re-enrolment campaign — existing users heal to the new method on their next sign-in. (On Android 9–13 the passkey is created in Google Password Manager, and only when an app the user can reach already signs in by passkey; a user without one sets it up at their next passkey sign-in or from the app's Settings.)

The old boolean passkeys_enabled field has been removed. The Admin API now rejects it with an HTTP 400 that names login_method as its replacement — update any provisioning scripts that still send it.

Simple QR

The default method. The user scans an on-screen QR code with the SenseCrypt Authenticator app, and face detection, liveness, and the match all run in the app, on their phone; the phone's hardware-bound key signs the result.

Your app redirects the browser to SenseCrypt's /authorize. SenseCrypt shows a branded email-entry page, then a page with a QR code, and the browser opens a live event stream and waits.

The user scans the QR with the Authenticator app. The app fetches the user's sealed face reference — a request gated so only the device registered to that email can fetch it — and runs the face check locally.

On a successful match, the phone reports the recovered proof over a signed request. SenseCrypt authorizes the session and pushes the result to the browser, which returns to your redirect_uri with the authorization code.

On a mobile browser the QR becomes a tap link that opens the Authenticator app on the same device, with App Store / Play Store fallbacks if it isn't installed. Sign-in sessions are short-lived (a few minutes) and the page counts down to expiry; a lapsed session sends your app the standard error=access_denied redirect.

Requires the SenseCrypt Authenticator app, installed and enrolled — there is no in-browser capture on this path (that is the separate Simple Webcam method).

Simple QR is not phishing-resistant. A scanned QR is a bearer link and is not bound to the origin the user is signing in to, so a user can in principle be socially engineered into scanning a QR from an attacker-initiated session ("QRishing"). When origin binding matters — high-value workforce apps, admin consoles — choose Passkeys instead.

Passkeys

The passkey method makes the possession factor a real FIDO2/WebAuthn passkey (ES256), and because WebAuthn binds each assertion to the requesting origin, sign-in is phishing-resistant. Select it by setting login_method: passkeys on the app.

SenseCrypt's passkey login has a deliberate twist over stock single-factor WebAuthn, so that it keeps the same person + device guarantee as Simple QR:

A verified WebAuthn assertion alone does not sign the user in. The browser assertion proves only possession, origin, and device proximity — it is parked. A separate, signed face report from the enrolled phone then proves personhood, and only when both halves are joined is the session authorized. Passkeys therefore give you phishing-resistance and a live face proof, not one instead of the other.

Where the passkey lives depends on the phone. On iOS and on Android 14 and later, the SenseCrypt Authenticator app is the phone's passkey provider and keeps the credential in the phone's secure hardware. Android 9–13 cannot host a third-party passkey provider, so there the passkey is stored in Google Password Manager, which syncs it to the user's Google account. A desktop sign-in typically runs cross-device: the browser shows the system passkey sheet, the phone approves over a proximity-checked channel, and the face check on the enrolled phone completes it. The user's phone must be enrolled.

A few things to know when you choose passkeys:

Browser support is required, with no fallback. The sign-in page needs a WebAuthn-capable browser and hard-fails on one that lacks it — it deliberately does not fall back to a QR, because silently downgrading a phishing-resistant method would defeat the point.
Passkeys are bound to your tenant's sign-in host. If an operator changes that host, existing passkeys stop matching and the console treats it as a re-enrolment event — worth knowing before you change hostnames.
Enrollment is unchanged. Passkeys are minted on the phone during the normal app enrollment, not by a browser ceremony, so there is nothing extra to build in your app.
What SenseCrypt checks. Every assertion's challenge, origin, rpId, user-presence flag, and ES256 signature. Authenticator attestation statements are not yet cryptographically verified.

Simple Webcam (enterprise)

Simple Webcam runs the face scan on a webcam attached to a trusted customer network, rather than on the user's phone — letting a desktop or kiosk user sign in without a phone. The trusted-network component plays the role the phone plays in the other methods; SenseCrypt still only verifies a cryptographic proof and remains biometric-blind. With no phone in the flow there is no possession factor: the face check and its liveness detection carry the sign-in on their own. Like Simple QR, and unlike Passkeys, it is not origin-bound.

Simple Webcam is available to enterprise customers — contact sales@seventhsense.ai. It is not a self-serve SaaS flow: on the hosted service the Admin API refuses login_method: webcam with HTTP 400 login_method_unavailable. In an enterprise deployment it is enabled by that deployment's licence.

Don't confuse Simple Webcam sign-in with the webcam capture in the admin console. The "Add auth user" screen (and the public try-it-live demo) can capture a photo from a webcam — but that is enrollment: the still image is forwarded to the isolated face-token minter and discarded, and only the sealed token is kept. It creates a user; it is not a way to sign in with a webcam in the browser.

What every method shares

These hold whichever method a user goes through, unless a bullet says otherwise:

Your integration is identical. A standard OIDC authorize-and-token exchange, or a SAML AuthnRequest and assertion. Nothing in your code path is biometric or method-specific.
SenseCrypt is biometric-blind. Face matching happens on the device (or the trusted-network component); no face image or template ever reaches SenseCrypt or your app. See Security.
The ceremony is recorded in the token. Every method mints an ID token carrying amr: ["face", "mfa", "pop"] and a SenseCrypt acr value asserting the face ceremony. See Tokens & sessions.
Single-use, per-sign-in rotation (Simple QR and Passkeys). The phone replaces the sealed face reference on every successful sign-in, so a captured proof cannot be replayed. Simple Webcam sign-ins do not rotate it.

How SenseCrypt works — the on-device biometric model and the four parties in a sign-in.
Passkeys and the face report — the two halves of a passkey sign-in as the Mobile SDK exposes them, if you build your own app.
OIDC & OAuth 2.0 — the protocol your app speaks to run any of these methods.
Authorization — the access gate that decides who may sign in, independent of the method.
Tokens & sessions — the amr/acr claims that record the ceremony.
Add Login (OIDC) — the hands-on quickstart.