On this page
What this integration does
Here SenseCrypt is the identity provider itself, not a step behind somebody else's. Your application is the OIDC client. It sends users to SenseCrypt to authenticate and gets back a signed ID token naming the enrolled user.
If your app already speaks OpenID Connect to another provider, your code does not change. You are repointing a discovery URL and a client ID. What changes for the user is that the SenseCrypt sign in page has no password field.
Your app stays an OIDC client
Standard authorization code flow, standard claims, standard libraries. Nothing SenseCrypt-specific has to be linked into your application.
SenseCrypt is the whole provider
This is not an authentication widget bolted onto a directory you run elsewhere. Users, groups, roles and audit logs live in SenseCrypt.
The proof is a face on a bound device
The user's enrolled device captures and matches. A single-use face token is what moves, and the server keeps no face image and no face template.
One client, more than one flow
The same configuration covers browser sign in, and CIBA is there when a backend needs to start authentication out of band. A CIBA push opens a device-bound face ceremony rather than a tap to approve.
What discovery, PKCE and PAR buy you
Three pieces of OpenID Connect do most of the security work here, and it is worth knowing which one buys what. Discovery removes hand-copied configuration. PKCE stops a stolen authorization code from being redeemed by anything except the client that started the flow. Pushed authorization requests move the request parameters into a back channel, so the browser never carries a URL an attacker can rewrite.
None of this is unique to SenseCrypt. It is current OAuth 2.0 security guidance. SenseCrypt implements it rather than treating it as an option you can forget to switch on.
- OpenID Connect discovery at the standard well-known URL.
- Authorization code flow with PKCE.
- Pushed authorization requests (PAR).
- ID tokens signed with a published key, served from a JWKS endpoint.
- Standard OIDC claims, plus the roles and permissions SenseCrypt computes for the user.
- CIBA for backchannel-initiated authentication.
Setup steps
You can do this in one sitting with an application you already have. Two things usually go wrong: a redirect URI that does not match byte for byte, and a claim mapping that assumes a field SenseCrypt does not send.
Run the first login on a real device. An OIDC round trip that passes in a test harness still tells you nothing about enrollment.
- Create an OIDC client in the SenseCrypt console.
- Register your redirect URI exactly as your application will send it.
- Point your application at the SenseCrypt discovery URL.
- Map the standard claims, and the roles claim, onto your user model.
- Enroll a test user and complete one face sign in.
What you get
You keep the application you have and change what happens on the far side of the redirect. Your user has no password to reuse, no code to be talked into reading out, and nothing to type into a page that only looks like yours.
The trade is honest: you gain a sign in with no shared secret in it, and you take on a device requirement.
Phishing-resistant because there is no secret
Sign in uses no password and no shared code. A one-time PIN appears once in the whole lifecycle, when a user binds a new device, sent by email and also by SMS when a mobile number is on file.
No face gallery to breach
Matching runs on the device and the server keeps no face image and no face template. The single-use face token is patent-pending, and a captured copy is worthless once spent.
Roles arrive in the token
SenseCrypt computes roles and permissions and emits them as claims; your application enforces them. SenseCrypt itself applies a default-closed group gate at sign in and capability checks on its admin console routes.
What it costs
One dollar per user per month with a 20-seat minimum, and customer identities bill as monthly active users. Signing-key custody in KMS is twenty dollars per key per month, and each tenant or custom domain past the first three is ten dollars per month. The 30-day trial takes no card.
Frequently asked questions
Does SenseCrypt need a proprietary connector?
No. SenseCrypt uses standard OpenID Connect. Your application reads the discovery URL and metadata. This is standards-based federation.
Where does the face match run?
The face match runs on-device. SenseCrypt keeps no face image and no face template on the server. It uses patent-pending face tokenization.
Which OAuth features does SenseCrypt support?
SenseCrypt supports OAuth 2.0 with PKCE and PAR. It also supports OIDC, SAML 2.0, SCIM 2.0, and CIBA.
What does my application receive after sign in?
Your application receives a signed ID token. The token carries standard OIDC claims about the enrolled user.
Related