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, using the algorithm your application registered (ES256 by default, or RS256), and check 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 the ID token signature via JWKS with the algorithm your application registered (ES256 by default, or RS256), selecting the key by kid (SenseCrypt may publish multiple keys during a rotation),
• lets you pass login_hint (SenseCrypt pre-fills the email-entry page from it),
• supports RP-initiated logout via the end_session_endpoint, and ideally back-channel logout as well (both below), and
• if you need refresh tokens, requests the offline_access scope.

Signing out

Clearing your own application's session cookie is only half of a sign-out. SenseCrypt keeps its own browser session, and while that session is alive your next /authorize is answered silently — an authorization code is minted with no face ceremony and the user lands straight back in your app. Users read that as a broken sign-out button.

To sign out properly, redirect the browser to the end_session_endpoint from discovery, with:

• id_token_hint — the ID token you received at sign-in. Keep it for this purpose. It is what proves which relying party is asking. Without it, SenseCrypt cannot check your post_logout_redirect_uri against your application: a request that names one is refused with an error page and nothing is signed out, and a request with no redirect asks the user to confirm and does not return to your app.
• post_logout_redirect_uri — where to send the browser afterwards. This must be registered on your application as a post-logout redirect URI, a separate allow-list from your /authorize callback URIs, and it is matched exactly (a query-string variant of a registered address is refused).

SenseCrypt then ends the browser session, revokes the user's refresh tokens for your application and for every other application that browser session signed in to, and sends a signed back-channel logout token to every relying party in that browser session that registered a backchannel_logout_uri — including your own application. A receiver must therefore accept a logout token for a session it has already ended itself.

Receiving back-channel logout

The reverse direction covers the sign-out your application did not start: the user signed out at another application sharing the same browser session, or something happened to the user. Register a back-channel logout URL on your application and SenseCrypt POSTs a signed logout_token there, server-to-server.

Every token names one session with a sid — the same sid your application saw in that session's ID token — so ending the session is a lookup, not a sweep. Your application also chooses which session endings it is told about, beyond the RP-initiated logout that is always on.

Back-channel logout has the whole receiving side: the registration rules, the initiator list, the token's claims, delivery and retries, and the checks your endpoint must make.

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.
• Back-channel logout — the receiving side in full.
• Security profiles — Standard vs FAPI 2.0/CIBA, and what each requires of your client.