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 same two things: the person (a live face check with liveness detection) and the device (a hardware-bound key). What changes between login methods is where the face is captured and what the possession factor is. 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 option where the face scan runs on a trusted customer network instead of a 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	The trusted-network component's key	No — not origin-bound	Enterprise, on request

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

Simple QR and Passkeys are chosen per application with the login_method field on the OIDC client (or SAML service provider). It takes one of two values:

simple_qr — Simple QR. This is the default for newly created apps.
passkeys — the FIDO2/WebAuthn method.

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 mints a passkey regardless of the app's current method, so 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.

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 Webcam is not a self-serve login_method value — see its section below.

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 every other method:

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.

The passkey is held by the SenseCrypt Authenticator app, which acts as your device's credential provider — the credential lives on the phone, never on the desktop. So a desktop sign-in always runs cross-device: the browser shows the system passkey sheet, the phone approves over a proximity-checked channel, and the face check 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.

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. Like Simple QR, and unlike Passkeys, it is not origin-bound.

Simple Webcam is available to enterprise customers on request — contact sales@seventhsense.ai. It is not a self-serve SaaS flow, and there is no login_method value you set yourself; it is provisioned as part of an enterprise deployment.

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

Whichever method a user goes through, the guarantees are the same:

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. The sealed face reference is replaced on every successful sign-in, so a captured proof cannot be replayed.

How SenseCrypt works — the on-device biometric model and the four parties in a sign-in.
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.