Security / Access and auth
Access and authentication
This page is about a real client deployment, which is private and behind a login. It is separate from the public demo, which is open on purpose so anyone can try it and holds only the fictional Spark Digital company. Everything below governs the client product, not the demo.
Sign-in uses a managed identity provider with no passwords.
Client dashboards and the AI connection authenticate through Auth0, a managed identity provider, using passwordless email one-time codes. You receive a code at your email address and enter it. There is no password to store, leak, or reuse.
Every access token is cryptographically verified.
Before a request is honoured, its token is checked end to end: the signature, who issued it, who it was issued for, and whether it has expired. The signing algorithm is pinned, so a token cannot smuggle itself in by claiming a weaker one.
Access is deny-by-default against an explicit allowlist.
Only emails on an explicit list of authorised people can get in. The default is to refuse. If no list is configured, the system will not start, rather than start in a state that lets everyone through.
Sessions use hardened, encrypted cookies.
Session cookies are encrypted, unreadable to scripts in the browser, restricted to HTTPS, and protected against cross-site request forgery. A stolen page cannot read the session, and a forged request cannot ride on it.
A new deployment self-tests before it serves traffic.
When a new version starts up it runs a self-test that proves identity enforcement, the data-privacy boundary, and the audit trail are all live. If any check fails, it refuses to start and the previous known-good version keeps serving. The rule is better down than up-but-compromised.
Related: how your data is isolated and where it is hosted, and the sub-processor that provides this identity layer.