Testing your integration

SenseCrypt is built around an on-device face ceremony, which is wonderful for real users and awkward for automated tests. This guide covers the affordances a dev/test deployment gives you so you can exercise your integration — from reading verification codes out of the logs to running device flows without real app-attestation tokens.

Everything here applies to development and test deployments only. The switches below are off by default and must never be enabled in production. A release build ships with them disabled.

Reading verification PINs from the logs

Email verification (and other one-time codes) normally arrive by email through Amazon SES. In dev you usually don't want to wire up SES at all — and you don't have to. There's no on/off switch: the app always attempts SES, but if a send fails (which is exactly what happens on a dev box with no AWS credentials), it falls back to writing the message to the application log instead of sending it.

So a fresh dev box needs no AWS credentials to boot. When a send falls back you'll see a pair of lines like:

ERROR ... SES send to user@example.com failed — falling back to stub (logged, not sent)
INFO  ... [SES fallback] user@example.com — ... Your verification code is: 123456

Admin self-service emails (verification / password-reset links) log similarly under [admin_email stub] …. Grab the PIN or link from that line in your test harness (for a PIN, the code is the last thing on its line) and feed it into your flow. To send real email in a dev environment instead, provide AWS credentials and a verified EMAIL_FROM — but for automated tests, log-scraping is simpler and dependency-free.

Verification codes for end users (the people signing into your relying party) are the ones you'll scrape here. Treat these logs as sensitive — the stub deliberately prints codes in plaintext, which is exactly why it's a dev-only path.

Running with app attestation disabled

In production, the SenseCrypt Authenticator app proves it is the genuine, unmodified store build via app attestation (Play Integrity on Android, App Attest on iOS) on every device payload fetch. That's a property of the app and platform, so it's a single deployment-wide control.

For local development and testing this floor is off by default (REQUIRE_APP_ATTESTATION=false), so device flows work without real attestation tokens from Google/Apple. You don't need to do anything to get this behavior in a dev deployment — just don't turn attestation on. (The same is true of reCAPTCHA Enterprise, which is off unless a site key is configured.)

Putting it together

Because the biometric step happens on the device, an end-to-end test drives the real ceremony against a throwaway tenant — the dev affordances above just remove the friction around it. A typical run:

1. Boot the backend with no AWS credentials (so email falls back to the log) and REQUIRE_APP_ATTESTATION=false, pointed at a throwaway tenant — never one that serves real users.
2. Enrol a test identity once with the SenseCrypt Authenticator app against that tenant; a single enrolled device can back your whole suite.
3. Run your app's login flow — the genuine authorization-code + PKCE ceremony — and complete the face step on that enrolled device.
4. Where a step needs a verification email (say, self-signup), scrape the PIN from the stub logs as shown above and feed it back into the flow.
5. Exchange the returned code at /v1/idp/oidc/token with your PKCE code_verifier, then assert on the resulting tokens — claims, scopes, and your API's authorization behavior.

Driving the genuine ceremony means your assertions cover the exact production path — the token, its claims, and the access gate your users hit — with nothing dev-only in the signing or token path.

Related

• Add login (OIDC) — the real authorization-code + PKCE flow your tests drive.
• Multi-tenancy — resolve endpoints from your tenant's discovery document; use a throwaway tenant for tests.
• Groups and access — the access gate a user must satisfy (a group attached to your client) before they can sign in.
• Refresh tokens and sessions — request offline_access to also test refresh in your harness.