01
Standard OIDC. Face-based authentication.
SenseCrypt is the authorization server, not a biometric widget bolted to one. Your application redirects to the authorization endpoint, the person completes the face ceremony, and your application redeems the code at the token endpoint and receives the two tokens it expects. Nothing in your code path is biometric, and there is no SDK of ours to ship inside your product.
One structural fact shapes every integration: each tenant is its own issuer, on its own hostname, signed with its own keys. You do not integrate against the platform in general, you integrate against one tenant's issuer, and you resolve every endpoint from that tenant's discovery document instead of hard-coding a path.
The scopes and claims that document advertises are the live ones for that tenant. Disable an attribute in the console and it leaves the advertised claims; define a custom scope and it appears. Read the document at runtime and your configuration stays true to the tenant.
Discovery is per tenant
Each tenant publishes an OpenID configuration document and a key set at its own host, naming every endpoint a library needs, including the PAR and backchannel endpoints.
Tokens are ES256, selected by kid
ID and access tokens are ES256 JWTs signed with the tenant's own key. Select the verification key by the token's kid and tolerate more than one, because a rotation publishes the outgoing key alongside the new one for a grace window.
The ceremony is recorded in the token
Interactive phone-based sign-ins carry an amr of face, mfa and pop, and auth_time records when the face ceremony completed. auth_time stays pinned to that ceremony and does not advance on refresh.
Many applications, one place to sign in
A person enrolls once. Every application registered behind the tenant inherits the same sign-in with no enrollment step of its own.
02
The authentication flow and its checks
The redirect carries what you would send any authorization server: response_type=code, your client_id and redirect_uri, the scopes, state, and a PKCE code challenge. SenseCrypt validates the client and the redirect URI, shows a branded email entry page that is identical whether or not the address is known to the tenant, then presents the QR the phone scans.
The phone runs detection, liveness and the match locally, then reports a signed result. The browser holds an event stream and never authenticates anything itself. Your application completes a normal token exchange and receives normal tokens.
Several hardening options that OAuth 2.0 deployments still treat as optional are not optional here.
PKCE is S256 only
The plain method is rejected outright, public and single-page clients are required to use PKCE, and a verifier presented against a session that stored no challenge is refused. Verifiers must be 43 to 128 characters from the RFC 7636 unreserved set.
Authorization Code flow only
There is no implicit and no hybrid flow to misconfigure. The authorization code is single use, short lived, and bound to the client and redirect URI that asked for it, and to the tenant before it is consumed, so a cross-tenant exchange fails without burning the code.
Redirect URIs are matched against an allow list
Exact matching, with tolerance for a trailing slash. A mismatch is refused rather than normalized into something that works.
Client authentication is pinned
A confidential client is registered for one method (client_secret_post, client_secret_basic, client_secret_jwt or private_key_jwt) and presenting a credential any other way fails, with no silent downgrade. Secrets are verified with Argon2id and support a rotation window so you can roll one without an outage.
Failures are deliberately opaque
An unknown client, a wrong secret and a wrong method all return the same error. At the token endpoint an unknown client, a user outside the application's groups and a suspended user all collapse to invalid_grant. There is no message to probe for which accounts or clients exist.
03
Pushed requests, and step-up without a session
Pushed authorization requests (RFC 9126) are supported and optional. Your backend posts the parameters and receives a request_uri, then the browser is redirected carrying only client_id and that reference, so no sensitive parameter is written into a browser URL, into an intermediary log, or into a referrer. The reference is single use, expires in five minutes by default, and is bound to the client that pushed it.
Step-up works differently here than on a provider that keeps a session. There is no identity provider side SSO session for end-user sign-in, so every interactive authentication is already a fresh face ceremony rather than a cookie being read back. The admin console is the exception: operators there do keep a browser session.
That makes max_age a precise instrument rather than a hint. Send it on the authorize request, or on a PAR push, and the age of the completed ceremony is checked at the token exchange. Too old and the exchange fails with login_required, and you restart the flow. A value of zero demands a ceremony completed essentially at exchange time.
Pushed parameters win
Per RFC 9126, values pushed to the PAR endpoint take precedence over any same-named query parameter on the authorize redirect. Face references never travel through PAR: they are staged server-side and fetched by the phone during the ceremony.
Two parameters control authentication
login_hint pre-fills the email page and max_age sets the freshness requirement. prompt, display and ui_locales are not read, so anything else you need to influence belongs in your own application logic.
Logout means invalidating tokens
With no browser session at the provider to clear, RP-initiated logout revokes the subject's refresh tokens and requires an id_token_hint to name the subject. A post-logout redirect URI must sit on its own allow list, separate from the authorize redirect list.
Introspection and client isolation
A confidential client may introspect its own tokens. Anything unverifiable, expired, revoked or belonging to another client comes back inactive with a 200 rather than an error, so the endpoint cannot be used to map what exists.
04
Controls beyond the OIDC flow
A protocol does not decide who may sign in. That is a separate, default-closed gate: an application admits a user only when the user is in at least one group attached to it, and an application with no attached groups admits nobody. It is checked at enrollment, when the phone fetches the sign-in payload, at the token exchange, and again on every refresh.
Fine-grained authorization is emitted rather than enforced. When your application requests one of your own APIs as an audience, and that resource server has RBAC enforcement switched on, the access token carries the user's effective permissions for that API. Your API validates the token and decides what each request may do.
Permissions are recomputed on every mint, refresh included, so removing a role or a group membership shrinks the next access token instead of waiting for an expiry.
Access checks fail closed
Suspend a user, delete them, un-enroll them, or remove them from an application's groups and they fail on their next token or refresh. Access does not survive to the end of a token lifetime.
Refresh tokens rotate, and reuse is treated as a breach
Each use of a rotating refresh token spends the presented one and mints a successor in the same family. Re-presenting a spent token outside a small overlap window revokes the entire family before failing.
Tenant isolation is cryptographic
A token minted in one tenant can never verify against another tenant's key set, because each tenant signs with its own key, and a client registered in one tenant is rejected on another tenant's issuer host.
Administrative actions are hash-chained
Console and administrative activity is written to a tamper-evident, hash-chained audit log per tenant. End-user sign-ins appear separately as a read-only activity stream, which is not hash-chained.
05
Getting connected
Create the OIDC client, give your library the tenant's discovery URL, attach at least one group so the gate lets somebody through, and seed enrollment from photos your organization already holds. The trial runs 30 days with no card, so a first integration can be working before procurement has started a conversation.
If you already run an identity platform, you do not have to leave it. Register SenseCrypt as an external OpenID Connect provider and that platform stays the identity platform, with the face ceremony sitting behind each sign-in. It is standards-based configuration on both sides rather than software you install.
Pricing is published rather than quoted, and the lines below are the whole of it for an OIDC deployment.
Published per-user pricing
Twenty seats is the minimum. In consumer deployments the count is monthly active users, so dormant registrations never reach the invoice.
Additional pricing items
A signing key kept in a managed key service is twenty dollars a month. The fourth tenant onward, and the fourth custom domain onward, are ten dollars a month each.
One provider, four protocol surfaces
The same tenant issues OIDC tokens, signs SAML assertions for older applications, takes provisioning calls over SCIM 2.0, and answers backchannel requests from services that have no browser at all.
06
Compare the details
| Endpoint | What it does |
|---|---|
| Discovery | Advertises this tenant's endpoints and its live scopes, claims and algorithms |
| JWKS | The tenant's ES256 public keys, selected by kid, with more than one present during a rotation |
| Authorization | Starts the interactive sign-in and hands the person to the face ceremony |
| Token | Exchanges the code, refreshes, and serves the CIBA and client credentials grants |
| Pushed authorization request | Pre-stages parameters over the back channel and returns a single-use request_uri |
| UserInfo | Returns the scope-released claims to the bearer of an access token |
| Introspection (RFC 7662) | Lets a confidential client check its own tokens. Anything else returns inactive with a 200 |
| Revocation (RFC 7009) | Revokes a refresh token family and denylists a matching access token until it expires |
| RP-initiated logout | Revokes the subject's refresh tokens. An id_token_hint is required to name the subject, because end-user sign-in leaves no provider-side session to clear |
| Backchannel authentication | Starts a CIBA request from a client that has no browser |
Discovery
- What it does
- Advertises this tenant's endpoints and its live scopes, claims and algorithms
JWKS
- What it does
- The tenant's ES256 public keys, selected by kid, with more than one present during a rotation
Authorization
- What it does
- Starts the interactive sign-in and hands the person to the face ceremony
Token
- What it does
- Exchanges the code, refreshes, and serves the CIBA and client credentials grants
Pushed authorization request
- What it does
- Pre-stages parameters over the back channel and returns a single-use request_uri
UserInfo
- What it does
- Returns the scope-released claims to the bearer of an access token
Introspection (RFC 7662)
- What it does
- Lets a confidential client check its own tokens. Anything else returns inactive with a 200
Revocation (RFC 7009)
- What it does
- Revokes a refresh token family and denylists a matching access token until it expires
RP-initiated logout
- What it does
- Revokes the subject's refresh tokens. An id_token_hint is required to name the subject, because end-user sign-in leaves no provider-side session to clear
Backchannel authentication
- What it does
- Starts a CIBA request from a client that has no browser
07
Frequently asked questions
Which OAuth 2.0 profile does this implement?
SenseCrypt supports OAuth 2.0 and OIDC, including FAPI 2.0, FAPI 2.0 Message Signing and FAPI-CIBA financial-grade flows. Configure PKCE, PAR, client authentication and response validation for the profile in use. Client credentials remain the separate flow for machine access.
Do we need an SDK from SenseCrypt?
No. Any OpenID Connect client library works. Point it at the tenant's discovery document, register your redirect URI, and the face ceremony happens between the redirect and the callback without appearing anywhere in your code.
How do we validate the tokens?
Fetch the tenant's key set, select the key whose kid matches the token header, verify the ES256 signature, then check iss, aud and exp. Tolerate more than one key: a rotation publishes the outgoing key alongside the new one until its grace window lapses, so never pin a single key.
Is there single sign-on across applications without a second face check?
No, and that is deliberate. There is no identity provider side SSO session for end-user authentication, so every interactive sign-in runs the face ceremony again from the start. What users reuse is the enrollment: one enrolled device works across every application behind the tenant. The admin console is the exception and does keep a browser session for operators.
Does SenseCrypt enforce our application's permissions?
No. It computes the user's effective permissions for the API you targeted and emits them in the access token, recomputed on every mint including refresh. Your API verifies the token, checks that aud matches its own audience, and authorizes each request against the permissions array.
Can we keep the identity platform we already run?
Yes. Register SenseCrypt as an external OpenID Connect provider there, and that platform keeps its directory, its policy and its existing application integrations while the face ceremony sits behind each sign-in.