Mobile (Authenticator)

The SenseCrypt Authenticator is the mobile app your end users use to approve sign-ins. It scans the QR code shown during a sign-in and performs the face match on the device. It runs on iOS and Android.

This is the end-user app. Your users install it from the App Store or Google Play. In the normal integration you do not embed anything — your app talks to SenseCrypt over standard OIDC/SAML (see Relying party) and users approve with this app.

If your product genuinely needs the face ceremony to happen inside your own app, the same capability is available as the Mobile SDK — provided on request, not published publicly.

What the app does

• Holds a device-bound passkey. SenseCrypt is built on real FIDO2/WebAuthn passkeys. During enrollment, the app generates a passkey key pair (ES256) in the phone's secure hardware (Secure Enclave on iOS, StrongBox-backed Keystore on Android); the private key never leaves that hardware. Every request the app makes to SenseCrypt is signed with this key.
• Performs the face match locally. At each sign-in, the app runs face detection, liveness, and matching on the device. No image or biometric template ever leaves the phone — SenseCrypt is biometric-blind.
• Approves sign-ins. After a successful match, the app reports the result to SenseCrypt, which completes the OIDC or SAML flow for your app.

The end-user experience

1. Your app redirects the user to SenseCrypt, which displays a QR code (and, for CIBA, emails it).
2. The user opens the Authenticator and scans the QR.
3. The user does a face scan.
4. The browser (or your backend) proceeds, and the user is signed in.

One of three sign-in methods. This QR scan is SenseCrypt's Simple QR flow. Because SenseCrypt is built on real FIDO2/WebAuthn passkeys (ES256), a passkey sign-in is a second method — and the phishing-resistant one, since WebAuthn origin binding ties the passkey to the site it was created for. Enterprise customers on a trusted network can also use a webcam face scan. Whichever method is used, the passkey proves the device and the live face scan proves the person. See How SenseCrypt works.

Enrollment

A user must enroll once before they can approve sign-ins. Enrollment binds a face to the person's account and provisions a device key. It happens one of three ways:

• Admin provisioning — an operator adds the user in the admin console (optionally from a photo).
• Self-signup — the user signs up directly from the app, when your application allows it. The app collects any required profile fields, then the face capture.
• Directory provisioning (SCIM) — your IdP creates the user as a pending shell; the user binds their face on first use of the app, which claims the shell in place. See SCIM.

Enrollment always proves control of the user's email (via a PIN, or via the emailed QR for CIBA/backchannel signup) before a device key is bound.

Security properties (for reference)

• Sign-in is strong multi-factor: a hardware-bound passkey (FIDO2/WebAuthn, ES256) plus a fresh, live face match on every authentication.
• Device keys rotate with a make-before-break ceremony so a device is never locked out mid-rotation.
• A suspended or deleted user's device keys are revoked immediately; ambiguous device state resolves to re-enrollment, never a silent fallback.

Related

• How SenseCrypt works — the end-to-end model.
• Security — biometric blindness and key custody.