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, or opens the link a sign-in sends it, 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.

A tenant can run its own build of this app. A tenant whose users should install an app under your name, icon, store listing and developer accounts registers that app on the console's Mobile App page, and the server verifies it instead of the stock Authenticator. Everything on this page then applies to your app. See Ship your own Authenticator app.

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); the private key never leaves that hardware. Every request the app makes to SenseCrypt is signed with this key.
• Provides the passkey for the passkey login method. Separately from the device key, the app acts as the phone's FIDO2/WebAuthn passkey provider (ES256) on iOS and Android 14+. On Android 9–13 the passkey is kept in Google Password Manager instead, which syncs it to the user's Google account.
• 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.
• Answers key requests in a Face PKI tenant. In a tenant created with Face PKI, the app also holds the user's face-locked post-quantum keys and answers an application's request for their public keys, a signature or a shared secret, after the same face scan.

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. A passkey sign-in with a real FIDO2/WebAuthn passkey (ES256) 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, with no phone involved. On the two phone-based methods, a key held on the phone proves the device and the live face scan proves the person. See How SenseCrypt works.

Approving a backchannel request

A CIBA sign-in has no browser on the phone's side. Depending on the application's alert channels, SenseCrypt pushes the request to the phone, emails the user a sign-in link, or leaves the alert to the application. The request also waits on the Authenticator's home screen until it expires. Tapping the notification, the link or the waiting request opens the Authenticator on an approval screen that names the application and shows its binding message, the text the application attached to the request. The user approves with a face scan, and the application receives its tokens.

Approving a key request (Face PKI)

In a tenant with Face PKI, an application can ask the user's keys to do one of three things. Each arrives as a push and an emailed link, and the push says what is being asked:

Opening it shows the same approval screen as a backchannel sign-in: the application's name and branding, the binding message, which the application must always send for a key request, and a countdown to expiry. When the request asks for tenant keys, the screen also says "This approval applies to all of Acme's apps". The key context the application asked for is never shown. After the face scan the app performs the key operation, delivers the signed result straight to the application, and only then tells SenseCrypt the request is complete. SenseCrypt never sees the result.

Four things can stop a key request, and each has its own screen:

• Not delivered. The application's endpoint refused the result. The user can try again, which re-sends the same signed result without another face scan, or cancel. If the endpoint could not be reached at all, the app shows its usual Connection failed sheet with the same two choices.
• Key not available. The user's identity on this device does not hold the key the request needs. The user is told to contact the application.
• Request can't be completed. The device cannot act on what the application sent. Again, the user contacts the application.
• Update required. The app uses a device protocol below 10. SenseCrypt refuses every request from such an app, key requests included, and the app asks the user to update it from the store.

A request the user cancels is reported to the application as access_denied, exactly like a declined sign-in, and one that expires as expired_token. The first three stops above are reported under their own names (delivery_failed, key_unavailable, invalid_request), so the application can show the right message on its side.

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, with a FIDO2/WebAuthn passkey (ES256) adding origin binding on the passkey method.
• 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.
• The app proves it is the genuine, store-distributed build through app attestation, checked against the identity the tenant registered. See Security.

Related

• How SenseCrypt works — the end-to-end model.
• Ship your own Authenticator app — running a tenant on your own build.
• Face PKI over CIBA — what an application sends to start a key request.
• Security — biometric blindness and key custody.