01
How SenseCrypt fits into Okta
Applications that trust Okta today go on trusting Okta. Group membership, sign-on policies, routing rules and the session your applications read are all left where they are. What gets delegated is a single step in the sequence. Where Okta would otherwise gather a password and, after it, a second factor, it redirects instead: the user completes a face check on the handset enrolled to them, and Okta resumes the sign in once the signed result arrives.
Trusting an external identity provider over OpenID Connect or SAML 2.0 is long-standing Okta functionality, and this integration uses nothing beyond it. The work is settings in two administration consoles, with no agent to install on a server and nothing new to keep patched.
The shape of that arrangement is what makes it worth piloting. A federation is a connection plus a routing rule, so widening it, narrowing it or withdrawing it altogether is an afternoon of configuration rather than a migration with a rollback plan attached.
Okta keeps issuing the session
Applications consume an Okta session exactly as they do today. SenseCrypt returns a signed assertion or ID token at the moment of authentication and holds no SSO session of its own for end users, so there is no second session lifetime to reason about or to revoke.
Where identity is verified
Okta redirects, the ceremony completes on the enrolled phone, and a signed result comes back naming that user. Okta then applies its own policy to the sign in the way it always has.
No secret changes hands
The routed flow contains no password and no one-time code. A caller posing as IT support has nothing to ask a user to read out, and a page copying your Okta sign in pixel for pixel has nothing to collect.
Start with one group
Okta evaluates routing rules per application and per group. Move a pilot team, watch the support queue for two weeks, then widen the rule once enrollment and device recovery have been exercised by people who were not on the project.
02
Choose your federation protocol
One link is enough and there is no reason to build both. For anything new, OpenID Connect is the stronger base: a discovery document supplies most of the settings, PKCE (RFC 7636) makes an intercepted authorization code useless to anyone but the client that opened the flow, and pushed authorization requests (RFC 9126) send the parameters over a back channel where nothing passing through a browser can rewrite them.
SAML 2.0 earns its place when the Okta tenant is already full of SAML connections and you would rather this one resemble what an on-call engineer has seen before. What differs in practice is certificate housekeeping and what the browser carries. For the person at the camera there is no difference at all.
Either way, what returns to Okta carries a SenseCrypt signature, and Okta checks that signature against a published key before it accepts a single claim inside it.
OIDC: configure from one URL
Okta pulls the endpoints and the verification keys straight out of the SenseCrypt discovery document, so a key rotation passes without an administrator editing the connection by hand.
SAML 2.0: an exchange of documents
Each side publishes metadata. The SenseCrypt file names the sign-in endpoint and the signing certificate; the Okta file describes its service provider role. Import one into the other and the trust exists, with assertions signed on the way out.
Authorization claims accompany the result
Roles and permissions are calculated on the SenseCrypt side and released as OIDC claims or SAML attributes. Okta writes them onto its user profile, and enforcement stays with your applications, unchanged.
The biometric never rides the wire
For the two mobile app methods, capture, liveness and matching stay on the user's handset. The network carries a signed authentication result and never an image or a template.
03
Configure the integration
Set aside an afternoon and a disposable test account. Two consoles stay open: SenseCrypt, where the Okta tenant is registered as a relying party, and Okta, where SenseCrypt appears on the external identity provider screens.
Claim mapping is where the hours go. Whatever SenseCrypt emits has to reach the Okta profile fields your downstream applications read, and a federation can round-trip perfectly while still depositing a user in an account nothing recognizes.
Make the first complete sign in a real one, with a real person and a real phone. Protocol correctness is the easy half and a test client will confirm it. Enrollment is the half your users experience, and the half the service desk hears about.
- In the SenseCrypt console, create a relying party record for the Okta tenant.
- Collect what Okta needs: a discovery URL for OIDC, or the metadata file for SAML 2.0.
- On the Okta side, create an external identity provider and import that configuration.
- Line the emitted claims up with Okta profile attributes, roles claim included.
- Add an Okta routing rule pointing the pilot group at the new provider.
- Switch on SCIM 2.0 if joiner and leaver changes should propagate without a ticket.
- Enroll one test user in the companion app, then sign in by face from start to finish.
04
Benefits, limits and pricing
Credentials remain the most productive thing an intruder can hold. The Verizon Data Breach Investigations Report puts them in 28% of breaches in its 2026 edition, and it measures the median time from a phishing message being opened to the link being clicked at under 60 seconds. Awareness training is competing with a stopwatch.
Routing Okta through SenseCrypt takes away the object being stolen rather than shortening the window in which it stays useful. Nothing in the flow can be reused: no password, no one-time code to recite to a caller, no push prompt that gets approved on autopilot at the end of a long day.
One distinction deserves stating precisely, because the market blurs it. Phishing resistance on this platform comes from the passkey path, where a real FIDO2/WebAuthn passkey (ES256) is bound to an origin by the browser, so a signature produced at a look-alike domain is not valid at yours. That is the property CISA points at in its phishing-resistant MFA guidance.
Where phishing resistance applies
The passkey path uses real FIDO2/WebAuthn passkeys through a roaming authenticator mobile app, and origin binding enforced by the browser is what earns the phishing-resistant label there. The QR path removes the shared secret an attacker would want, but it carries no origin binding, so the claim names a path and not a platform. Phone sign-in also combines a live face check with a key bound to the enrolled device.
What the server stores
IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment. SenseCrypt is biometric-blind: there is no gallery to breach, to subpoena or to migrate.
Testing scope and evaluation results
Liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2 addresses the attack class where something is held up to the lens: a photograph, a replayed screen, a mask. Face recognition is evaluated in the NIST Face Recognition Technology Evaluation under Seventh Sense's own name, participation since 2021. NIST evaluates algorithms and certifies nothing, and the report card is public at pages.nist.gov/frvt/reportcards/11/seventhsense_000.html.
Published pricing
Seats list at one dollar per user each month against a floor of 20. A non-exportable signing key in a managed key service adds twenty dollars a month, and the key cannot be copied out by anyone, including us. Tenants and custom domains are free up to three, then ten dollars a month apiece. The 30-day trial runs without a card.
05
Frequently asked questions
Does Okta stay in control of policy and sessions?
Yes. Okta keeps the directory, the groups, the routing rules and the session your applications consume. SenseCrypt authenticates the person and returns a signed result. For end-user authentication there is no SenseCrypt-side SSO session running in parallel, so session lifetime remains an Okta decision. The SenseCrypt administration console does keep its own browser session, but that is for administrators only.
What biometric data does SenseCrypt store?
IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment.
Do users need their phone every time they sign in?
For the two mobile app methods, yes. Liveness and matching happen in the companion app on the enrolled phone, which is precisely why the device being signed in to needs no enrollment and no software of its own. A webcam method that avoids the second device is offered to enterprise customers on a trusted customer network rather than as a self-serve option; contact sales@seventhsense.ai. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
Is this phishing-resistant?
On the passkey path, yes, through FIDO2/WebAuthn origin binding: the passkey signs only for the origin it was registered against. The QR path takes away the credential an attacker would try to steal, which is a real but different property, so we decline to describe the platform as phishing-resistant without naming the path the claim applies to. Phone sign-in also combines a live face check with a key bound to the enrolled device.
Can users and groups be provisioned automatically?
Yes, over SCIM 2.0 (RFC 7644). Joiner, mover and leaver changes stay in step between Okta and SenseCrypt instead of being reconciled by hand, which matters most on the day somebody leaves.
What does the audit trail cover?
Administrative actions in the SenseCrypt console are written to a hash-chained, tamper-evident log. End-user sign-in events are recorded separately as a read-only activity stream and are not hash-chained. No customer-facing endpoint or screen exists for verifying the chain, so treat the console log as tamper-evident by construction rather than as something you can independently prove inside your own tooling.