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>.<domain> 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 on-device face ceremony is entirely handled by SenseCrypt and the Authenticator app — your RP code just performs the normal redirect and token exchange.

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.