Use SenseCrypt with OpenID Connect

An application that already talks OpenID Connect to some other provider needs no code changes. A discovery URL is repointed, a client ID is swapped, a redirect URI is registered. Authorization code flow, the standard claims and the library you already trust all stay exactly where they are.

Behind the redirect is a full identity provider, not a login component leaning on a directory kept somewhere else. Accounts, groups, roles, provisioning and the administrative surface belong to the same product, which is why a small team can adopt it without also standing up a directory to hold the accounts.

No SenseCrypt-specific library has to be linked into your build. A conformant OIDC client is the whole of the client side here.

Three parts of the specification carry most of the security weight here, and each buys something different. Discovery eliminates configuration copied by hand and keeps working through a key rotation. PKCE (RFC 7636) means an authorization code intercepted in transit cannot be exchanged by anybody who does not hold the verifier that opened the flow. Pushed authorization requests (RFC 9126) submit the request server to server, so the URL the browser follows carries a reference instead of parameters an attacker could rewrite on the way past.

None of this is proprietary. It is the current security guidance around OAuth 2.0 (RFC 6749), and the only thing worth adding is that these are defaults here rather than switches an administrator can leave off.

Connections use hybrid post-quantum TLS (X25519MLKEM768). Separately, the face-token construction uses NIST 140-3 approved symmetric and hash primitives exclusively: AES-256-GCM, HKDF-SHA256 and SHA-256. No proprietary or non-approved cryptographic primitives are used in that construction. Its quantum-safe property is separate from the transport and federation algorithms.

• Discovery served from the standard well-known document.
• Authorization code flow, with PKCE required rather than optional (RFC 7636).
• Pushed authorization requests (RFC 9126).
• OAuth 2.0 (RFC 6749) underneath, without proprietary extensions on top.
• Signed ID tokens, and a JWKS endpoint to fetch the verification key from.
• The standard claim set, plus the roles and permissions computed for that user.
• CIBA for backchannel authentication, with FAPI-CIBA support for financial-grade flows.
• SCIM 2.0 (RFC 7644) for user and group provisioning.
• Hybrid post-quantum TLS (X25519MLKEM768) on the connection itself.

With an application that already exists, this is usually one sitting. Two failures account for most of the lost time: a redirect URI that differs from what the application actually sends, even by a character, and a claim mapping written against a field this provider does not emit.

Decide your session lifetime deliberately rather than inheriting one. SenseCrypt runs a fresh ceremony for each authorization request and keeps no provider-side SSO session for end-user authentication, so how long a person stays signed in is a property of your application and its cookie policy. The administration console does hold a browser session, but that is for administrators, not for the users of your application.

Do the first login against a real enrollment on real hardware. A round trip that succeeds against a test client has proved your redirect handling and nothing whatever about the enrollment experience, which is the part your support inbox will be about.

1. Create the OIDC client record in the SenseCrypt console and keep the client ID.
2. Enter the redirect URI byte for byte as your application will send it.
3. Configure your application with the SenseCrypt discovery URL.
4. Bind the standard claim set, roles included, onto your user model.
5. Set session lifetime and refresh behavior explicitly rather than by default.
6. Enroll one test user in the companion app, then complete a single face sign in.

The application is unchanged; everything different sits beyond the redirect. Nobody signing in keeps a password to reuse elsewhere, holds a code that can be talked out of them, or has anything to type into a page dressed up as yours. The Verizon Data Breach Investigations Report measures the median gap between a phishing message being opened and the link being clicked at under 60 seconds, which is a fair reason not to rest the defense on user caution.

The trade deserves stating plainly. What arrives is a sign in that contains no shared secret at all. What comes with it is a hardware dependency, an enrollment step, and a recovery procedure somebody has to own by name.

For applications needing a stronger statement than the absence of a secret, the passkey path adds origin binding: a real FIDO2/WebAuthn passkey (ES256) signs only for the origin it was registered against, and that is the path we describe as phishing-resistant. Phone sign-in also combines a live face check with a key bound to the enrolled device.