01
How SenseCrypt IdP 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 then 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. There is no pre-built connector. Federation is standard OIDC or SAML 2.0 configuration on both sides. There is no agent to install on a server and nothing new to keep patched.
Because a federation is a connection plus a routing rule, widening it, narrowing it or withdrawing it is configuration rather than a migration with a rollback plan attached.
Okta keeps issuing the application session
Applications consume an Okta session exactly as they do today. SenseCrypt IdP returns a signed ID token or assertion at the moment of authentication. Its own browser session is summarized in the fact sheet on this page; decide its lifetime alongside Okta's.
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 password changes hands
The routed flow contains no password and no one-time code, so a caller posing as IT support has nothing to ask a user to read out. Origin-bound phishing resistance belongs to the passkey method; Simple QR removes password entry but is not origin-bound.
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 replacement have been exercised by people who were not on the project.
02
Choose your federation protocol
One link is enough; 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. For the person at the camera there is no difference at all.
Either way, what returns to Okta carries a SenseCrypt IdP signature, and Okta checks it against a published key before it accepts a single claim.
OIDC: configure from one URL
Okta reads the endpoints and verification keys from the tenant's 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 IdP file names the sign-in endpoint and the signing certificate; the Okta file describes its service provider role. Import each into the other side and the trust exists.
Authorization claims accompany the result
Roles and permissions are calculated in SenseCrypt IdP and released as OIDC claims or SAML attributes. Okta writes them onto its user profile, and enforcement stays with your applications.
The face image never crosses the network
On the two phone methods, capture, liveness and matching stay on the user's handset. The network carries a signed authentication result, never an image or a template.
03
Configure the integration
Set aside an afternoon and a disposable test account. Two consoles stay open: SenseCrypt IdP, where Okta is registered as an OIDC application or a SAML service provider, and Okta, where SenseCrypt IdP is added as an external identity provider.
Claim mapping is where the hours go. Whatever SenseCrypt IdP 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. A test client confirms protocol correctness; enrollment is the half your users experience.
- In the SenseCrypt IdP console, register Okta as an OIDC application (or as a SAML service provider).
- Attach at least one SenseCrypt IdP group to the application; with none attached, nobody can sign in.
- Collect what Okta needs: the discovery URL for OIDC, or the metadata file for SAML 2.0.
- In Okta, add an external identity provider and import that configuration.
- Map the emitted claims to Okta profile attributes, the roles claim included.
- Add an Okta routing rule that sends the pilot group to the new provider.
- Turn on SCIM 2.0 if joiner and leaver changes should propagate without a ticket.
- Enroll one test user in the app, then sign in by face from start to finish.
04
What the change buys, and what it asks
Credentials remain the most productive thing an intruder can hold. The Verizon DBIR puts credentials in 28% of breaches in its 2026 edition, and it measures the median time from opening a phishing email to clicking its link at under 60 seconds. Awareness training is competing with a stopwatch.
Routing Okta through SenseCrypt IdP removes the password from the sign-in rather than shortening the window in which a stolen one stays useful: no password, no one-time code to recite to a caller, no push prompt approved on autopilot.
Phishing resistance is stated precisely. It belongs to the passkey method, where a FIDO2/WebAuthn passkey is bound to your origin by the browser, so a signature produced at a look-alike domain is not valid at yours. That is the property CISA points to in its phishing-resistant MFA guidance.
05
SenseCrypt IdP at a glance
06
Frequently asked questions
Does Okta stay in control of policy and sessions?
Okta keeps the directory, the groups, the routing rules and the session your applications consume. SenseCrypt IdP authenticates the person and returns a signed result. Set SenseCrypt IdP's own browser session to fit Okta's session policy, or turn it off so every routed sign-in runs a fresh face ceremony.
Is there an Okta connector to install?
No. There is no pre-built connector. Federation is standard OIDC or SAML 2.0 configuration on both sides. Okta's external identity provider feature does the work on its side.
Do users need their phone every time they sign in?
For the two phone methods, yes: liveness and matching happen in the SenseCrypt Authenticator app on the enrolled phone, which is why the device being signed in to needs no enrollment and no software of its own. Simple Webcam runs only in a licensed enterprise deployment, on secure terminals. Captures are processed inside that deployment, and the method adds no phone possession factor, so it is not multi-factor. Contact sales@seventhsense.ai about that deployment.
Is this phishing-resistant?
On the passkey method, yes, through FIDO2/WebAuthn origin binding: the passkey signs only for the origin it was registered against. Simple QR removes password entry, which is a real but different property, and it is not origin-bound. Require the passkey method where origin-bound phishing resistance is the requirement.
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 IdP. Provisioning creates the account; the user still enrolls before they can sign in by face.