Glossary

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.

Custom domain — A hostname a tenant owns, such as auth.example.com, that once verified (a TXT record for ownership and a CNAME for routing) serves the tenant's sign-in pages and protocol endpoints with the issuer mirroring that host. The console never serves on it. See Custom domains.

Sign-in host — The one WebAuthn Relying Party ID a tenant's passkeys are bound to: the slug host by default, or a custom domain or its registrable domain. Changing it retires every passkey in the tenant; users re-enrol with a face check.

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 a push, the emailed sign-in QR or the application's own alert), rather than through a browser redirect. Supports poll, ping, and push token delivery (push is not available to FAPI-profile clients, whose issuer advertises poll and ping only).

Face PKI — A tenant setting, fixed at creation, that gives every user post-quantum keys in two families: ML-KEM (FIPS 203) and ML-DSA (FIPS 204). The keys are derived on the phone from the user's face token and their live face, so only the user's face unlocks them. The tenant chooses the parameter set for each family (face_pki_kem_algorithm, face_pki_dsa_algorithm). By default, keys are derived per application and per context, one keypair of each family for every pair: two applications that ask for the same context get different keys, even in the same tenant. An application that an admin allowed can ask for tenant keys instead. See Face PKI over CIBA and Key scope.

Face-PKI ceremony — A CIBA request that asks a user's face-locked keys for their public keys (public_keys), a signature over a hash (sign), or the shared secret of an ML-KEM ciphertext (decapsulate). The user approves it on the phone with a face scan; the phone delivers the signed result straight to the application's face_pki_delivery_endpoint, and the ID token carries a face_pki receipt naming that delivery. The receipt also names the key scope (scope): app or tenant.

Key scope (face PKI) — The namespace that a face-PKI context lives in: app (the default) or tenant. In the app scope, each application gets its own keys. In the tenant scope, every application in the tenant that uses the tenant scope gets the same keys for the same user and context. Only an application that an admin allowed (face_pki_tenant_scope_allowed) can use tenant. An application chooses the scope of a CIBA ceremony with face_pki_scope. See Key scope.

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.

Security profile — Which rule set a tenant or an application runs under: Standard, or FAPI 2.0/CIBA (plain_fapi). A tenant's profile is fixed at creation; a Standard tenant's applications can each adopt it. See Security profiles.

FAPI 2.0 / FAPI-CIBA — The OpenID Foundation's Financial-grade API security profile, and its CIBA companion. On SenseCrypt it means: pushed authorization requests only, asymmetric client authentication, sender-constrained tokens, no RS256, authorization codes of at most 60 seconds, and, with CIBA, a signed backchannel request and, by default, certificate-bound tokens. An application can accept DPoP-bound CIBA tokens instead (ciba_dpop_binding_allowed, which needs dpop_bound_access_tokens on). That application is outside the certified FAPI-CIBA profiles. See FAPI 2.0/CIBA clients.

DPoP — Demonstrating Proof of Possession (RFC 9449). The client signs a short-lived proof JWT (typ: dpop+jwt) with its own key on every request; the access token is bound to that key. Available to every application. See Sender-constrained tokens.

Mutual TLS client authentication — RFC 8705 tls_client_auth (PKI: a registered subject DN plus trust anchors) and self_signed_tls_client_auth (a registered certificate), plus certificate-bound access tokens. Available on a deployment whose discovery publishes mtls_endpoint_aliases.

JAR — JWT-Secured Authorization Request (RFC 9101). A signed request object whose claims are the authorization request. SenseCrypt accepts one at /par and at the CIBA endpoint, never at /authorize.

JARM — JWT Secured Authorization Response Mode. The authorization response parameters arrive as the claims of one signed response JWT, requested with response_mode=jwt (or query.jwt / fragment.jwt / form_post.jwt). See Signed requests and responses.

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 — A JWT asserting the user's identity, returned from the code exchange and signed with the algorithm its application registered (ES256 by default, RS256 if chosen). 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 — Two unrelated claims share this name. On an access token it binds the token to its refresh-token family, so revoking the family invalidates the access token. On an ID token it is the id of the OP browser session, emitted only to an application that registered a backchannel_logout_uri (the value it will later see in a logout token). Never correlate one with the other.

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.

Sender-constrained token / cnf — An access token bound to a key the caller must prove on every request, instead of a plain bearer token. The cnf (confirmation) claim names the thumbprint: jkt for a DPoP key, x5t#S256 for a client certificate. A token carries at most one.

Logout token — The signed JWT SenseCrypt POSTs to an application's backchannel_logout_uri when a session it was signed in to ends. Typed logout+jwt, carries events and sid, and never a nonce. See Back-channel logout.

OP browser session — SenseCrypt's own session behind the sc_op_session cookie, established by a face ceremony. While it is live a second application on the tenant can be authorized without another ceremony, and prompt=none answers silently. Its id appears as the sid in an ID token only for an application that registered a backchannel_logout_uri — the only holder that has anything to correlate it with.

iss (response parameter) — RFC 9207: the issuer identifier travels on the authorization response — a plain parameter on the ordinary response modes, a claim inside the response JWT under JARM — so a client federating several OPs can detect a mix-up. Advertised as authorization_response_iss_parameter_supported.

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).

Passkey (FIDO2 / WebAuthn) — SenseCrypt supports real FIDO2/WebAuthn passkeys (ES256), used through a FIDO2 roaming-authenticator app. The passkey is a separate credential from the device key above. On iOS and Android 14+ the Authenticator app holds it in the phone's secure hardware; on Android 9–13 it is stored in Google Password Manager, which syncs it to the user's Google account. This is SenseCrypt's phishing-resistant sign-in path — WebAuthn binds each assertion to the calling site's origin, so the credential can't be replayed against a look-alike site. The passkey proves the device; the live-face check proves the person. It is one of three sign-in methods, alongside Simple QR (scan an on-screen QR, then a face scan in the SenseCrypt mobile app, matched on-device) and the enterprise-only Simple Webcam (a webcam face scan on a trusted customer network — available to enterprise customers, contact sales@seventhsense.ai).

App attestation — A hardware-integrity proof (Play Integrity on Android, App Attest on iOS) that only the genuine, store-distributed app the tenant registered can pass. A per-tenant policy with off, audit and enforce modes; the deployment setting is the default for tenants on the stock Authenticator. There is no per-application opt-out. See Ship your own Authenticator app.

App-link host — The hostname a tenant's sign-in links are issued on and that publishes the two app-link documents (apple-app-site-association, assetlinks.json). Tenants on the stock SenseCrypt Authenticator use the deployment's shared app host; a tenant that runs its own app uses its own slug host by default, or a verified custom domain.

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.

First-party app — A tenant's own mobile app, built on the Mobile SDK and registered on the console's Mobile App page in place of the stock Authenticator. Only such an app can use in-app sign-in. See Ship your own Authenticator app.

In-app sign-in — A sign-in that a first-party app performs inside itself: a face scan on the enrolled phone with no browser, no redirect and no QR, after which the app holds IdP-issued, DPoP-bound tokens. Off by default, opt-in per application, and driven by the Mobile SDK's SignInFlow. See In-app sign-in.

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. SenseCrypt does this when an account is permanently deleted, which destroys the key-wrapping material of every tenant on it. Deleting a single tenant revokes its access and retires its signing keys, but is not a crypto-shred.

Related

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