Technology

The identity provider behind the face

The Authenticator handles passwordless authentication. Underneath sits the rest of the platform: applications, a SCIM-ready directory, roles, scopes, machine credentials, and audit.

Patent-pending face tokenization

Photothe one already on file

Biometric templatederived on device, then discarded

Biometric KDFa key only this face re-derives

CBOR face tokenseals the verifier; the challenge goes to the serverface code verifier · face-encryptedface code challenge · SHA-256 · to the server

Live face + tokenthe device signing in needs no enrollment

Biometric KDFkey re-derived from the live face

Unsealed and signedonly a matching face; the device signs it

signed on the device · matched on the serverSHA-256(face code verifier)=face code challenge Verified: no biometric stored or sent

The mental model

If you know PKCE, you already know face tokens

In OAuth PKCE

Prove the client finishing the flow is the one that started it: publish the hash of a secret up front, reveal the secret later.

same proof

In a face token

Prove the person: the secret is sealed under your face, and only your live face can reveal it.

In OAuth PKCEIn a face tokenIn OAuth PKCEThe client keeps a random code_verifier privateIn a face tokenA random face_code_verifier is encrypted under a random key recoverable from your face. The Biometric Key Derivation Function returns the encrypted face_code_verifier (the face token) and the face_code_challengeIn OAuth PKCEOnly its hash, the code_challenge, is shared up frontIn a face tokenThe server stores the token and the face_code_challenge, never a biometricIn OAuth PKCEProof: present the verifier; the server hashes and comparesIn a face tokenProof: your live face unseals the verifier, your device signs it, and the server matches it to the stored hash

Not a biometric template: nothing to link or reverse, and only the live face unlocks it. A quantum-safe face token (symmetric-and-hash cryptography only), carried over hybrid post-quantum TLS (X25519MLKEM768).

Unlinkable. Irreversible. Revocable. Renewable

ISO/IEC 24745 names the four properties protected biometric data must have. Face tokens have them by construction: properties of the mathematics, not promises in a policy.

Unlinkable

Every enrollment is fresh randomness: two tokens from one face share nothing and can't be linked. AEAD binds each token to its tenant, so it can't be reused anywhere else.

Irreversible

Knowing a token tells you nothing about the face behind it. What it holds is a sealed random verifier, and the sealing is designed so there is no way back to an image or a template.

Revocable

A face can't be canceled; a token can. Delete it and it can never verify again, so a compromise ends at revocation instead of following someone for life.

Renewable

Re-enroll from the same face at any time: a new random verifier, a new challenge, no relationship to the old token. Renewal never spends the biometric, and never reveals it.

The vocabulary is the standards' own: ISO/IEC 24745:2022 specifies these protection properties for biometric information, and ISO/IEC 30136:2018 defines how they are tested and reported.

ISO/IEC 24745:2022 — Biometric information protection ISO/IEC 30136:2018 — Performance testing of biometric template protection schemes

What's inside

Everything you need to own your identity stack

Applications

OIDC + SAML

Register OIDC clients and SAML service providers side by side. Per-app credentials, redirect URIs, branding, and token settings.

How it works, in the docs

Directory & SCIM

SCIM 2.0

A managed user directory with custom attributes. Your upstream directory stays the source of truth; SCIM 2.0 pushes users and groups in.

How it works, in the docs

Roles & RBAC

Define roles and permissions once, then assign them across applications and APIs for fine-grained, capability-based access.

How it works, in the docs

Scopes & Attributes

Shape exactly what each app receives. Map directory attributes into scopes and claims for least-privilege tokens.

How it works, in the docs

APIs & M2M

Protect resource servers with scoped tokens and issue machine-to-machine credentials for service-to-service calls.

How it works, in the docs

Activity & Audit

Every sign-in, grant, and admin action on a read-only audit trail. Live activity, with CSV export.

How it works, in the docs

The console

Applications, people, and keys in one console

Register apps, manage users and roles, and revoke credentials the moment someone leaves. Isolated tenants, per-app branding, delegated admin. Every change is audited, and every sign-in is visible live.

Multi-tenant: isolated apps, keys & users

Per-app branding & redirect URIs

Per-app billing model: seats or active users, set at creation

How it works

From redirect to signed token

SenseCrypt is standard OIDC and SAML at the wire, so it drops into the login flow you already have.

Register your app

Create an OIDC client or SAML service provider, register your redirect URI, and copy the client credentials. Endpoints resolve from the OIDC discovery document.

Redirect to sign in

Send users to /authorize. They scan a QR with the SenseCrypt app and verify live; liveness and matching run on their own phone.

Receive a signed token

We return an ID token (or SAML assertion) signed with your tenant's keys. Verify it like any other provider, no SDK required.

Side by side with the login you run today

Traditional login

Passwords stored server-side, phished, stuffed, and reset all day.

SMS and TOTP codes that can be intercepted or fatigued into a tap on Approve.

A per-device enrollment ceremony for every new laptop and phone.

Helpdesk resets granted to whoever tells the most convincing story.

Biometric templates pooled in a database you have to defend.

SenseCrypt

No password exists: a live face, verified against a registered device.

Prompts name the app and the exact request, and only the enrolled person's live face approves.

Enroll once from the photo on file. The phone they already carry then verifies them for any device they use.

Re-establish access by presenting your face. No security questions to guess.

Biometric-blind: the platform holds only face tokens that can't be linked across services or reversed into a face.

Built on open standards

Every card links to its primary spec, so your review can start from the source.

OpenID Connect

OIDC Core 1.0

OpenID Connect is the identity layer on OAuth 2.0: ID Tokens and UserInfo, issued per tenant with its own signing keys.

OIDC Discovery

Discovery 1.0

Every tenant publishes /.well-known/openid-configuration, so endpoints, scopes, and keys resolve from one URL.

OAuth 2.0

RFC 6749

The delegated-authorization framework underneath every integration: authorization code, refresh, and client-credentials grants.

Authorization Code

RFC 6749 §4.1

Front-channel code, back-channel exchange: the recommended interactive flow, and the only grant used for user sign-in.

PKCE

RFC 7636

Proof Key for Code Exchange defeats authorization-code interception. It is required on every authorization flow, not optional.

PAR

RFC 9126

Pushed Authorization Requests: OAuth parameters travel the back channel as a request_uri, never the browser.

Bearer Tokens

RFC 6750

Standard Authorization: Bearer token presentation that works with any compliant API gateway or middleware.

OAuth 2.1 posture

oauth.net/2.1

PKCE for all clients, exact redirect-URI matching, no implicit or password grants: OAuth 2.1's requirements, enforced today.

OAuth Security BCP

RFC 9700

The IETF's current security best practice for OAuth deployments, and the hardening baseline the endpoints follow.

CIBA

OpenID CIBA Core

Your server starts sign-in with a user hint, the user approves on their phone, and your server collects the tokens. No browser, no redirect.

SAML 2.0

OASIS Standard

Signed assertions, SP- and IdP-initiated SSO, and attribute mapping. Any SP connects from pasted metadata.

SCIM 2.0

RFC 7644

Standard user and group provisioning: create, update, deprovision. Built to match the request shapes real Okta and Entra connectors send.

Inside the token

What the token says

Each card below is checkable. Decode one token and the evidence is in the claims your app already validates.

ES256 · JWKS

Signed and verifiable

Every ID and access token is an ES256 JWT signed with the tenant's own keys. Your app verifies the signature against the tenant's published JWKS, selecting the key by kid.

amr: face · mfa · pop

MFA recorded in the token

The amr claim reads face, mfa, and pop: a fresh on-device face match, multi-factor, and a device-bound key proof of possession. The token records how the user signed in.

max_age

Step-up on demand

Send the OIDC max_age parameter to require a fresh face ceremony for a sensitive action. The check runs at the token exchange, and auth_time records when the ceremony happened.

refresh_token

Lifecycle fails closed

Access is re-evaluated on every refresh, so a suspended or removed user fails closed before the access token expires. Reuse of a spent refresh token revokes its whole family.

Adoption

Familiar concepts, your deployment

Feels familiar from day one

If your team has integrated Auth0, Okta, or Entra ID, SenseCrypt will feel familiar: applications, scopes, RBAC, and SCIM provisioning behave the way you expect, and any standard OIDC or SAML library works unmodified. Quickstarts for Next.js, React, Express, and FastAPI cover the first integration end to end.

Read the docs

Hosted SaaS or self-managed

Run on our hosted platform, or deploy the same identity provider inside your own infrastructure: a standard Python service behind your TLS proxy, backed by PostgreSQL, serving OIDC, SAML, SCIM, and the admin console from a single process.

Self-hosting guide

Stand up your identity provider in an afternoon

Point a standard OIDC library at your tenant's discovery URL and validate the token. The quickstarts show every step.