On this page
What this integration does
Okta stays your identity platform. Every application you have already wired to it keeps pointing at Okta, and your groups, policies and session rules do not move. One step in the middle changes: instead of Okta collecting a password and then a second factor, Okta hands the user to SenseCrypt and the user looks at the camera.
There is no Okta Integration Network listing to install and no agent to deploy on a server. Okta already knows how to trust an external identity provider over OIDC or SAML 2.0. That is the whole mechanism.
Okta stays the front door
Your applications keep their existing Okta configuration and Okta still issues the session they consume. SenseCrypt never becomes something your app inventory depends on.
SenseCrypt owns the proof step
Okta redirects the user to SenseCrypt, the face ceremony runs on the user's own enrolled device, and SenseCrypt returns a signed token or assertion. Okta then completes the sign in as it always did.
Nothing typed, nothing read out
Sign in carries no password and no shared code. A page that looks exactly like your Okta sign in therefore collects nothing an attacker can replay.
Route a pilot group first
Okta routing rules work per application and per group. Put one team on face login, leave everyone else on the current method, and widen it when the support queue says it holds.
Choose OIDC or SAML 2.0
You need one federation, not both. OIDC is the better choice for anything new. The discovery document configures most of the connection for you, PKCE binds the authorization code to the client that started the flow, and pushed authorization requests move the request parameters into a back channel where a browser cannot rewrite them.
Pick SAML 2.0 when Okta already federates that way and you want this connection to look like the ones your team maintains. The ceremony on the device is identical either way. Only the wire format differs.
OIDC: one discovery URL
Okta reads the SenseCrypt discovery document and learns the authorization endpoint, the token endpoint and the signing keys from it. You paste a URL and a client ID instead of maintaining a certificate by hand.
SAML 2.0: two metadata files
SenseCrypt publishes IdP metadata with the sign in URL and the signing certificate. Okta exports its service provider metadata back. Each side imports the other, and SenseCrypt signs every assertion it issues.
The face check does not vary
Capture and matching run on the user's own device. What travels back is a single-use face token, so the protocol you pick changes nothing about what the server keeps: no face image and no face template.
Roles ride along in the claims
SenseCrypt computes roles and permissions and emits them. Okta maps them onto its own user profile, and your applications decide what they allow.
How you set it up
Budget an afternoon, not a project. The work happens in two consoles and nothing is installed on a server or an endpoint. The step that usually runs long is claim mapping, because Okta profile attributes have to line up with what SenseCrypt emits before your applications see anything useful.
Do the first end-to-end sign in with a test account and a real phone. A federation that works in a test harness tells you nothing until a person has actually enrolled.
- Register Okta as a relying party in the SenseCrypt console.
- Copy the SenseCrypt discovery URL, or download the SAML 2.0 metadata file.
- Add SenseCrypt in Okta as an external identity provider.
- Map the SenseCrypt claims onto Okta profile attributes.
- Write an Okta routing rule that sends the pilot group to SenseCrypt.
- Turn on SCIM 2.0 if you want users and groups kept in sync.
- Enroll one test user and run a face login end to end.
What you get
The result is a sign in with no secret in it. There is no password to phish, no code for a caller to talk a user into reading out, and no push notification to approve by reflex at two in the morning. What proves the person is a face check on a device that was bound to them.
The rest of the platform arrives with it, because SenseCrypt is a full identity provider rather than an authentication widget.
Phishing has nothing to collect
A fake sign in page captures what a user types, and users type nothing here. The face token is spent the moment it is used, so a copy taken in transit is worthless.
Liveness is certified, recognition is evaluated
Liveness holds iBeta ISO 30107-3 certification at Level 1 and Level 2, which covers presentation attacks at the camera such as a printed photo or a mask. Face recognition entered the NIST evaluation in 2021, then FRVT and later split into FRTE and FATE, and we maintain it through our latest submissions. That is evaluation, not certification.
The platform underneath
Role-based access control, multi-tenant isolation and audit logs are part of SenseCrypt. SenseCrypt computes and emits the roles; your applications enforce them.
What it costs
One dollar per user per month with a 20-seat minimum. Signing-key custody in KMS adds twenty dollars per key per month, and each tenant or custom domain past the first three costs ten dollars per month. The 30-day trial takes no card.
Frequently asked questions
Does SenseCrypt have a prebuilt Okta connector?
No. SenseCrypt connects to Okta through open standards only. You use OIDC or SAML 2.0 with metadata and a discovery URL.
Where does SenseCrypt store biometric data?
SenseCrypt keeps no face image and no face template on the server. Face matching runs on-device. SenseCrypt uses patent-pending face tokenization. A face becomes a single-use face token.
Does SenseCrypt replace Okta?
No. Okta stays your identity platform. SenseCrypt works as the external identity provider (IdP) for face login.
Can SenseCrypt provision users with Okta?
Yes. SenseCrypt supports SCIM 2.0. You can sync users and groups with Okta.
Related