Relying party

Your application integrates with SenseCrypt as a standard OIDC relying party (RP) — or, for enterprise SSO, a SAML service provider. Because SenseCrypt speaks conformant OIDC and SAML, you do not need a SenseCrypt-specific SDK: any well-maintained OIDC/SAML client library for your stack works.

The approach

Point your existing OIDC client at the tenant's issuer and let it discover the endpoints:

1. Configure the library with the issuer URL https://<your-tenant>.sensecrypt.com and your client_id (plus a client_secret for confidential apps; SPAs use PKCE).
2. Let the library read {issuer}/.well-known/openid-configuration for the authorization_endpoint, token_endpoint, userinfo_endpoint, and jwks_uri.
3. Use the Authorization Code flow with PKCE (S256). Most modern OIDC libraries do PKCE by default.
4. Validate the ID token against the tenant's JWKS (ES256), checking iss, aud, and exp.

The user-facing sign-in ceremony is handled entirely by SenseCrypt and the Authenticator app — your RP code just performs the normal redirect and token exchange.

Under the hood, SenseCrypt is built on real FIDO2/WebAuthn passkeys (ES256): a device-bound passkey proves the device, and a fresh, live face check proves the person. A tenant can use any of three sign-in methods, all invisible to your RP — the OIDC/SAML contract is identical for each:

• Simple QR — the user scans an on-screen QR and does a face scan in the Authenticator app, matched on the device.
• Passkeys — a real FIDO2/WebAuthn passkey, with the Authenticator acting as a roaming authenticator. This is the phishing-resistant path: the passkey is bound to the WebAuthn origin, so a credential proven to one origin can't be replayed against another.
• Simple Webcam (enterprise only) — a webcam face scan on a trusted customer network, matched on the workstation rather than a phone. Available to enterprise customers; contact sales@seventhsense.ai.

Library compatibility checklist

When choosing or configuring a library, make sure it:

• supports the Authorization Code flow with PKCE S256 (required),
• discovers endpoints from the OpenID configuration (don't hard-code),
• verifies ES256 ID token signatures via JWKS and selects keys by kid (SenseCrypt may publish multiple keys during a rotation),
• lets you pass login_hint (SenseCrypt pre-fills the email-entry page from it), and
• if you need refresh tokens, requests the offline_access scope.

Worked example

The Add Login (OIDC) quickstart walks through the exact requests — discovery, the authorize redirect, the code exchange, ID-token validation, and userinfo — using plain HTTP so you can map them onto whatever library you use.

Related

• Add Login (OIDC) — the step-by-step quickstart.
• OIDC & OAuth 2.0 — flows, client types, and endpoints.
• Tokens & sessions — validating and using the tokens.