01
The client side of this integration
An application that already talks OpenID Connect to another provider needs no new code. A discovery URL is repointed, a client ID is swapped, a redirect URI is registered. The authorization code flow, the standard claims and the library you already trust all stay where they are.
Behind the redirect is a full identity provider, not a login component leaning on a directory kept somewhere else. Accounts, groups, roles, provisioning and administration belong to the same product, so a small team can adopt it without also standing up a directory.
No SenseCrypt-specific library is needed. A conformant OIDC client is the whole of the client side.
Standard authorization code flow
Authorization code with PKCE is the default and recommended flow, with a token endpoint, a JWKS endpoint and the standard claim set. Implicit and hybrid response types exist per application, are off unless you enable them.
Directory included
Groups, roles, tenants, provisioning and administrative records ship in the same product. You are not assembling an identity layer from a login component plus a separately bought directory.
Proof happens on the enrolled handset
On the two phone methods, the enrolled phone captures, checks liveness and matches locally. The device your user signs in on needs no enrollment, which makes kiosks and shared machines workable, provided they end sessions between users.
One registration, several flows
The same registration covers browser sign-in and CIBA, where a backend starts authentication out of band. A CIBA request sends a backchannel push that starts the same device-bound face check on the enrolled phone, rather than a tap-to-approve prompt.
02
What the protocol layer gives you
Three parts of the specification carry most of the security weight. Discovery removes hand-copied configuration and keeps working through a key rotation. PKCE (RFC 7636) means an intercepted authorization code cannot be exchanged by anybody who does not hold the verifier that opened the flow. Pushed authorization requests (RFC 9126) submit the request server to server, so the URL the browser follows carries a reference instead of parameters an attacker could rewrite.
None of this is proprietary; it is current security practice around OAuth 2.0 (RFC 6749). PKCE is S256-only and required for public and single-page clients; PAR is available to every client and optional.
- Discovery served from the standard well-known document.
- Authorization code flow with PKCE (RFC 7636), S256 only.
- Pushed authorization requests (RFC 9126).
- OAuth 2.0 (RFC 6749) underneath, without proprietary extensions.
- Signed ID tokens (ES256) and a JWKS endpoint for the verification keys.
- prompt and max_age evaluated at the authorization endpoint.
- The standard claim set, plus the roles and permissions computed for that user.
- CIBA for backchannel authentication, with FAPI-CIBA for financial-grade flows.
- SCIM 2.0 (RFC 7644) for user and group provisioning.
03
Wiring it up
With an existing application, set aside an afternoon. Two failures account for most lost time: a redirect URI that differs from what the application sends, even by a trailing slash, and a claim mapping written against a field this provider does not emit.
Decide session behavior deliberately; the fact sheet on this page sets out SenseCrypt IdP's browser SSO session. Send max_age, or prompt=login, when an action needs a fresh face ceremony. Your application's own session and cookie policy still decide how long a person stays signed in to it.
Do the first login against a real enrollment on real hardware. A round trip against a test client proves your redirect handling, not the enrollment experience your support inbox will be about.
- In the SenseCrypt IdP console, register an OIDC application and keep the client ID.
- Attach at least one SenseCrypt IdP group to the application; with none attached, nobody can sign in.
- Enter each redirect URI exactly as your application sends it; paths match byte for byte, trailing slash included.
- Configure your application with the tenant's discovery URL.
- Map the standard claims, roles included, onto your user model.
- Set session lifetime, refresh behavior and freshness (max_age) explicitly.
- Enroll one test user in the SenseCrypt Authenticator app, then complete a face sign-in.
04
What you gain, and what you take on
The application is unchanged; everything different sits beyond the redirect. Nobody signing in keeps a password to reuse elsewhere or holds a code that can be talked out of them. The Verizon Data Breach Investigations Report measures the median time from opening a phishing email to clicking its link at under 60 seconds, which is a fair reason not to rest the defense on user caution.
The trade deserves stating plainly. What arrives is a sign-in with no password in it. What comes with it is a phone dependency on the phone methods, an enrollment step, and a device-replacement procedure somebody has to own by name.
Where an application needs origin-bound phishing resistance, require the passkey method: a FIDO2/WebAuthn passkey signs only for the origin it was registered against. Simple QR removes password entry but is not origin-bound.
Authorization data in the claims
Roles and permissions are computed here and emitted as claims for your application to enforce. The access gate is default-closed: a group check runs at sign-in, and capability checks guard every administration console route.
Device replacement
A lost phone is replaced through a verified contact (a one-time PIN by email, with SMS where a number is on file) and a new device key. The face is not re-registered, and the live face check is still required at sign-in.
05
SenseCrypt IdP at a glance
06
Frequently asked questions
What exactly does my application receive after a sign-in?
A signed ID token with the standard OpenID Connect claims about the enrolled user, plus the roles and permissions computed for them. Your application validates the signature, issuer and audience against the keys in the tenant's JWKS, then applies its own authorization rules to the claims.
Do we have to change our application code?
Not if it already implements OpenID Connect properly. A new discovery URL, a new client ID and a registered redirect URI cover it. The two parts that usually need attention are the claim mapping and an exact match on the redirect URI.
Does SenseCrypt IdP keep users signed in between applications?
It can, if the tenant enables it. Session persistence is configurable per tenant in the IdP portal: set how long a session lasts, or don't persist sessions at all. A new face ceremony runs when the session or the application's freshness policy requires it. RP-initiated logout ends the provider session and revokes refresh-token families; an id_token_hint is required to name the subject. SAML Single Logout is not supported.
Can SenseCrypt IdP sit behind Auth0 or another platform?
Yes, where that platform accepts an external OpenID Connect identity provider. Register the platform in SenseCrypt IdP as an OIDC application, attach a group, and add SenseCrypt IdP on the platform side as an external provider. The platform keeps its users, rules and sessions; only the proof step moves.
Which device does the checking?
On the two phone methods, capture, liveness and matching happen on the user's enrolled phone, and the SenseCrypt Authenticator app on that phone is required. The device being signed in to needs no enrollment. 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.
In what sense is the face token quantum-safe?
The face-token construction uses symmetric and hash primitives only (AES-256-GCM, HKDF-SHA256 and SHA-256), which is why it is described as quantum-safe. The statement is about the token, not the whole platform. Federation signatures are classical: ID and access tokens are ES256, and SAML assertions are RSA-signed.