Which flow should I use?

SenseCrypt supports a deliberately small, standards-based set of flows. Choosing between them comes down to three questions: is a human signing in, or is it a machine? — is a browser present at login? — and does your app speak OIDC or SAML? In every human flow, the biometric face proof happens on the user's own device (their phone in the Simple QR and passkey flows); the flow only decides how your app starts and finishes the exchange.

Decision tree

The rules, in words

• A machine or service calling the Management API — no human, no browser → client-credentials (M2M). You get an access token for a service account with scoped roles. See Machine-to-machine.
• A human, and your app is a SAML service provider — → SAML 2.0 SSO, with SenseCrypt acting as the SAML IdP. See SAML SSO.
• A human, OIDC, with a browser at sign-in (a web app, single-page app, or native app that can open a browser) → Authorization Code flow with PKCE. This is the common case. See Add Login (OIDC) or a framework quickstart.
• A human, OIDC, but no browser on the device initiating the sign-in (a kiosk, a CLI, a call-center agent verifying a caller) → CIBA, where the request is decoupled and the user approves on their own phone. See CIBA back-channel.

What SenseCrypt does not support

So you don't spend time looking for them: SenseCrypt intentionally does not implement the Resource Owner Password Credentials (password) grant, the OAuth Device Authorization grant, or Dynamic Client Registration. The Implicit (id_token, id_token token) and Hybrid (code id_token, code token, code id_token token) response types exist for relying parties that need them, but are off by default and must be enabled per application — Authorization Code + PKCE is the default and the recommended flow, the quickstarts use nothing else, and an application on the FAPI 2.0 profile is code-only (see OIDC & OAuth 2.0). response_type defaults to code, and code_challenge_method is S256 only. These omissions are deliberate — each is either superseded by Authorization Code + PKCE or incompatible with an on-device biometric model.

Four more absences worth knowing about, all deliberate:

• A request object at /authorize. JAR request objects are accepted at the PAR endpoint and at the CIBA endpoint, never at the authorization endpoint (request_parameter_supported: false) — a request there is refused request_not_supported, and a request_uri that isn't one SenseCrypt minted is refused request_uri_not_supported.
• Encrypted tokens and responses. SenseCrypt signs; it does not offer JWE id_tokens, UserInfo responses or authorization responses, and advertises no *_encryption_* metadata.
• CIBA user_code. There is no per-user secret on a passwordless issuer to verify one against, so backchannel_user_code_parameter_supported is false and registering the opt-in is refused.
• SAML Single Logout (SLO). There is no SLO endpoint or LogoutRequest handling. For OIDC, use RP-initiated and back-channel logout instead.

Learn more