SenseCrypt Docs
Reference

Glossary

Definitions of the terms used across the SenseCrypt documentation — protocol, authorization, key-custody, and device concepts, in the precise sense SenseCrypt uses them.

Terms are defined in the specific sense SenseCrypt uses them. Where a word means different things in different contexts (for example role), each sense is called out.

Identity and tenancy

Tenant — An isolated directory that is its own OIDC/SAML issuer, with its own signing keys, users, groups, apps, and configuration. Resolved from the request host. Tenants are hard isolation boundaries; a token minted for one tenant never validates against another.

Issuer — The iss value in tokens, equal to a tenant's host-derived URL. Each tenant is its own issuer.

Directory — The set of users belonging to one tenant. Synonymous with the tenant's user population.

Auth user — An end user in a tenant's directory. Distinct from a console admin (who administers the IdP itself).

sub (subject) — A stable, per-tenant pseudonymous identifier for a user, safe to use as your application's primary key. It is not the internal database row id.

Pending shell — A user record (created by SCIM or the admin console) that has a profile and group memberships but no face binding yet. A pending shell cannot sign in; the person binds their biometric on first use of the Authenticator app.

Protocol surfaces

OIDC / OAuth 2.0 — The primary sign-in protocol. SenseCrypt supports the authorization-code flow with PKCE, refresh tokens, client credentials (for M2M), and CIBA.

SAML 2.0 — An alternative federation protocol for enterprise service providers. SenseCrypt is a SAML identity provider (IdP).

SCIM 2.0 — A provisioning protocol that lets your identity provider create, update, deactivate, and delete users and groups in a tenant automatically.

CIBA — Client-Initiated Backchannel Authentication. A flow where the relying party starts authentication and the user approves out-of-band (via the emailed sign-in QR), rather than through a browser redirect. Supports poll, ping, and push token delivery.

PAR — Pushed Authorization Request (RFC 9126). The client pushes authorization parameters to the IdP and receives a request_uri to use at /authorize, so the parameters can't be tampered with in the browser.

PKCE — Proof Key for Code Exchange (RFC 7636). SenseCrypt supports the S256 method only; plain is rejected. PKCE is mandatory for SPA (public) clients.

Discovery document — The /.well-known/openid-configuration JSON that advertises a tenant's endpoints and capabilities.

JWKS — JSON Web Key Set, served at a tenant's jwks_uri. Contains the tenant's current public signing key (plus any in-grace keys during rotation). Select the verification key by kid.

Tokens

ID token — An ES256 JWT asserting the user's identity, returned from the code exchange. Contains sub, iss, aud (your client_id), auth_time, and scope-released profile claims.

Access token — An ES256 JWT used to call APIs. Contains iss, sub, aud, scope, jti, and — when audience-targeted at an RBAC-enforcing resource server — a permissions claim.

Refresh token — An opaque (non-JWT) token issued only when the offline_access scope is granted. Exchanged for new access tokens; may rotate on each use.

kid — Key ID. For OIDC it's the RFC 7638 JWK thumbprint of the public key; for SAML it's the certificate's SHA-256 fingerprint. Used to select the verification key.

jti — A unique token identifier that makes an individual access token revocable (it can be added to a denylist until it expires).

sid — A claim binding an access token to its refresh-token family, so revoking the family invalidates the access token.

amr / acr — Authentication Methods References / Authentication Context Class Reference. SenseCrypt sets these to assert the device-key proof and on-device face match. The acr is a SenseCrypt-defined value, not a standards-registered one.

Token family — The lineage of a refresh token and its rotated successors. Reusing a spent token outside a short overlap window revokes the whole family. The family has an absolute lifetime fixed at issuance.

Authorization

The word role means two unrelated things. Keep the axes separate.

Access gate — The default-closed rule that decides whether a user may sign in to an application: a user may sign in only if they belong to at least one group attached to that app. An app with zero attached groups admits nobody. Re-evaluated on every token and every refresh.

Group — A named set of users. Groups drive both the sign-in access gate (when attached to an app) and role assignment (roles can be conferred through group membership).

Resource server — An Auth0-style representation of one of your APIs, identified by an immutable audience string. Carries an enforce_rbac flag.

Audience — The aud a token is minted for. Requested via ?audience= (Auth0 spelling) or RFC 8707 ?resource=; resource wins if both are sent. A token's audience is your client_id by default, or a resource server's audience when one is requested and granted.

Permission — A single action string (for example read:invoices) scoped to one resource server. Bundled into roles.

Role (downstream / app RBAC) — A per-tenant named bundle of permissions assigned to end users, directly or through groups. Shapes the permissions claim in end-user access tokens. SenseCrypt emits permissions but never enforces them — your API does.

permissions claim — The array of a user's effective permissions for a targeted API, emitted only when the resource server has enforce_rbac on. Recomputed on every token mint, including refresh.

Capability — A fixed entity:verb string (for example oidc_apps:create) that governs what a console administrator or M2M app may do in the IdP itself. Bundled into admin roles / M2M roles. A separate axis from downstream RBAC.

Admin role / M2M role (console capabilities) — Named bundles of capabilities for administrators (admin role) or service accounts (M2M role). Unrelated to the downstream role above, despite the shared word.

Scope — Controls which profile claims are released into tokens. Standard scopes (profile, email, phone, address) behave as in OIDC; custom scopes are definable. A claim is released only when a granted scope releases it and the user has a value.

Attribute — A typed profile field (string, integer, date, choice, phone number, and more) in a tenant's attribute schema. Attributes are released as claims via scopes.

Machine access

M2M app — A machine-to-machine application (a service account) that authenticates with the client_credentials grant to call the tenant's Management API or the SCIM endpoints. Distinct from an OAuth client used for user sign-in.

Management API — The tenant's administrative API, addressed by the audience "{issuer}/v1/admin/". M2M tokens targeting it carry the app's capabilities in permissions.

SCIM token — An opaque bearer token (prefixed ssct_) minted in the console for SCIM provisioning. The "Secret Token" mode most external IdP connectors expect. Tenant-scoped; shown once.

Device and biometrics

Face token — A sealed, opaque AEAD envelope produced at enrollment that only the same live face can open on-device. SenseCrypt cannot decrypt it. The only plaintext the server reads from it is a tamper-evident context_id binding it to its tenant.

Signed request — A device-plane request signed with the phone's hardware-resident ES256 key over a canonical string (protocol version, method, path, device id, key id, timestamp, body hash). The server verifies against the stored public key.

Device key — The public half of a device's hardware key pair, stored server-side. The private key never leaves the phone's Secure Enclave (iOS) or StrongBox-backed Keystore (Android).

App attestation — A hardware-integrity proof (Play Integrity on Android, App Attest on iOS) that only the genuine store-distributed Authenticator app can pass. A deployment-wide floor with no per-client opt-out.

Face-token minter — A separate, firewalled service that seals an uploaded photo into a face token during admin provisioning. Device-driven flows mint tokens on the phone and never involve it.

Key custody

KEK — Key-Encryption Key. The key that seals signing-key material at rest. It is held outside the database (optionally in AWS KMS), so a database dump is inert without it.

Software custody — The default signing-key custody model: the private PEM is sealed at rest in the database as an AES-256-GCM envelope under the KEK.

KMS custody — A per-tenant opt-in custody model: the private key is generated in and never leaves AWS KMS. The database stores only the key's ARN.

Crypto-shred — Permanently and irreversibly destroying a tenant's sealed key material, so it can never be recovered. Used for offboarding, right-to-erasure, or revoking access after a compromise.

  • Concepts — narrative explanations of most of these terms.
  • Error codes — the error taxonomy.
  • Security — the key-custody and biometric-blindness model.

On this page