On this page
What the OIDC provider is
SenseCrypt is the identity provider, not a biometric bolted onto one. Your application hands sign-in over and gets standard OpenID Connect tokens back. What differs is the ceremony in the middle: the user proves presence with a live face on a bound device instead of typing a password.
That matters for effort. The protocol your application speaks does not change, so the work is configuration rather than code.
A standard OIDC client library is enough
Discovery, the authorization code flow, the token endpoint, and the ID token all behave the way the specification says. If your framework already speaks OIDC, it already speaks SenseCrypt.
The face ceremony and the tokens come from one service
There is no second vendor to keep in step, and no seam between the biometric and the identity provider for an integration bug to hide in.
One IdP in front of many applications
Users enroll once. Every application you register behind SenseCrypt inherits the same phishing-resistant sign-in without its own enrollment step.
How the OIDC flow works
Your application sends the user to SenseCrypt, exactly as it would to any other authorization server. The user completes the face ceremony on their enrolled device, where both the capture and the match run. SenseCrypt returns an authorization code, and your application exchanges it for an ID token and an access token.
The hardening sits in the parts of OAuth 2.0 that many deployments still treat as optional. We do not.
PKCE binds the code to the client that asked for it
An intercepted authorization code is worthless without the verifier held by the original client. That closes the code interception attack on public clients.
PAR keeps the request out of the URL bar
With pushed authorization requests the parameters travel over the back channel and the browser carries only a reference. Nothing sensitive lands in a redirect URL, a proxy log, or a referrer header.
There is no password leg to attack
Most OIDC deployments are only as strong as the credential behind the login page. Here there is no credential, so credential stuffing and replay have nothing to work with.
What comes with the protocol
A protocol on its own does not run an access model, so the identity provider ships with one. Roles and permissions are resolved at sign-in and written into the token your application receives. Tenants are isolated from each other, and administrative activity is recorded.
Be precise about where enforcement happens. This is where teams misread vendor pages, including ours.
SenseCrypt computes roles, your app enforces them
We resolve each user's roles and permissions and emit them as claims. Your application reads the claim and decides what the request is allowed to do.
Two gates we do enforce ourselves
Sign-in runs a default-closed group check, so a user with no granted group gets no token. The admin console checks capabilities on every route.
Tenant isolation is applied at the query
Every query is scoped to the authenticated account and tenant. A reference to another tenant's object returns a not-found, so the response does not confirm that the object exists.
How it fits the standard
The value of a standards IdP shows up in a mixed estate. Older applications keep using SAML, new ones use OIDC, your directory drives provisioning over SCIM, and a back-end service can start a sign-in with CIBA, all from one service.
Everything below is plain specification behavior. No proprietary SDK is needed to use any of it.
- OpenID Connect, with a discovery document at the well-known path
- OAuth 2.0 authorization code flow with PKCE
- Pushed authorization requests (PAR)
- SAML 2.0 with signed assertions and standard metadata
- SCIM 2.0 for user provisioning and deactivation
- CIBA for client-initiated backchannel authentication
How to turn it on
Register your application as an OIDC client, point your library at the discovery URL, and enroll users from photos you already hold. The 30-day trial takes no card, so the first integration can happen before any procurement conversation.
The per-user rate is the starting line, not the invoice.
One dollar per user per month, list price
A 20-seat minimum applies. Customer identity deployments bill on monthly active users, not on every account that ever registered.
Line items outside the seat rate
Signing-key custody in KMS costs twenty dollars per key per month. Each tenant and each custom domain past the first three adds ten dollars per month.
Federate instead of migrating
SenseCrypt can sit in front of your current identity provider as an external IdP over OIDC. Your directory, your policy, and your existing application integrations stay where they are.
Frequently asked questions
Does SenseCrypt support OAuth 2.0 with PKCE?
Yes. SenseCrypt supports OAuth 2.0 with PKCE and PAR. It uses the authorization code flow.
Which standards does the IdP support?
SenseCrypt supports OIDC, OAuth 2.0, SAML 2.0, SCIM 2.0, and CIBA.
How do users sign in?
Users sign in by face. Face matching runs on-device. The sign-in is passwordless and phishing-resistant.
Does the OIDC provider give RBAC and audit logs?
Yes. SenseCrypt gives role-based access control (RBAC), multi-tenant isolation, and audit logs.
Related