SenseCrypt Docs
SDKs & apps

Mobile (Authenticator)

The SenseCrypt Authenticator app for iOS and Android — the end-user app that approves sign-ins with a face scan. Integrators do not embed it.

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. You do not embed the Authenticator in your own application — your app integrates over standard OIDC/SAML (see Relying party).

What the app does

  • Holds a device-bound key. During enrollment, the app generates a key pair in the phone's secure hardware (Secure Enclave on iOS, StrongBox-backed Keystore on Android). 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.

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 key 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.

On this page