Concepts

SenseCrypt is a multi-tenant identity provider (IdP). Your users sign in with a face scan on their phone instead of a password, and your app talks to SenseCrypt over the same standard protocols you already use with any other IdP: OIDC / OAuth 2.0, SAML 2.0, and SCIM 2.0.

These pages explain the ideas you need before integrating — the "why" behind the endpoints. If you just want to wire up sign-in, jump to the Get Started quickstarts and come back here when a design decision needs context. Every concept page cross-links to the matching quickstart and to the exact API reference operation, so you can move from mental model to working code without guessing.

The big picture

Four properties shape almost every design decision in SenseCrypt. Keep them in mind and the rest of the system falls into place.

• Passwordless and biometric. Every sign-in is gated by an on-device face proof combined with a hardware-bound device key. There are no passwords to phish, reset, or leak. See How SenseCrypt works.
• Biometric-blind. Face matching happens entirely on the user's phone. SenseCrypt never receives, stores, or processes face images or embeddings — it only verifies a cryptographic proof (a PKCE-style hash comparison). There is deliberately no code path anywhere in the service that decrypts biometric material. See Security.
• Standards in, standards out. Your app integrates with plain OIDC, SAML, or SCIM. The biometric ceremony sits behind the standard authorize/token exchange (or the SAML AuthnRequest/Response) and is invisible to your code. See OIDC & OAuth 2.0, SAML, and SCIM.
• Multi-tenant by design. Each tenant is its own OIDC issuer and SAML IdP on its own hostname, with its own signing keys, and is a hard isolation boundary. See Multi-tenancy.

How the pieces fit together

A typical integration touches several of these concepts at once. Reading them in this order builds the model from the outside in:

1. How SenseCrypt works grounds everything — the passwordless, on-device biometric model and the four parties in a sign-in (browser, phone, your app, SenseCrypt).
2. Multi-tenancy & issuers explains the single most important structural fact: you integrate against one tenant's issuer, and you resolve its endpoints from discovery.
3. OIDC & OAuth 2.0 or SAML 2.0 is the protocol your app speaks to actually get a user signed in.
4. Tokens & sessions covers what you receive back and how to validate and refresh it.
5. Authorization governs who is allowed to sign in and what they may do in your downstream APIs.
6. SCIM 2.0 and CIBA are the two additional surfaces you reach for when you need directory provisioning or decoupled, no-browser authentication.

Pages in this section

A note on accuracy

SenseCrypt is a security product, and these docs are written to be trustworthy about it. Where a page describes a rule ("PKCE is S256-only", "the access gate re-runs on every refresh", "logout requires an id_token_hint"), that rule reflects the actual behavior of the service. Where a value is tenant-specific or negotiated — endpoint paths, supported scopes, token lifetimes — the docs tell you to resolve it from discovery or your configuration rather than hard-coding it. When in doubt, discovery is the source of truth.