Security model
Walk the defense-in-depth model layer by layer — authentication, database-level authorization, rate limiting, and anomaly detection containing each other's failures.
Layered by design
No single control is trusted to hold on its own.
A request passes through independent layers, and a failure in one layer is contained by the next.
MFA and sessions
Enforcement, grace periods, and step-up authentication.
Account recovery
Five recovery paths with anti-enumeration.
Single sign-on
SAML 2.0 and OIDC with domain-based discovery.
Layer 1 — Passkey-first authentication
The strongest available method is always offered first:
- Passkeys (WebAuthn) with user verification required — phishing-resistant and bound to the device.
- Magic links and passwords as alternatives.
- SSO (SAML 2.0 and OIDC) for organizations, with domain-based identity provider discovery.
MFA is enforced for elevated roles, with a defined grace period for newly elevated accounts. See MFA and sessions.
Layer 2 — Step-up for sensitive operations
Authentication is risk-based, not binary. Sensitive administrative operations — MFA resets, role changes, forced password resets, session revocation — require a fresh, recent second-factor proof (AAL2) even when the actor already holds a valid session. A stolen session token alone cannot perform these actions.
Layer 3 — Authorization at the database
Authorization is enforced by Postgres Row-Level Security (RLS) on more than 100 tables. Policies evaluate the authenticated identity on every query, inside the database itself:
- Client applications hold only the anonymous key; they can never bypass policy.
- Privileged (service-role) access is confined to server-side edge functions and never reaches a browser.
- A compromised client or a bug in the application layer still cannot read rows the policy denies.
Layer 4 — Rate limiting
All authentication surfaces sit behind atomic, auth-aware rate limiting:
- A primary bucket keyed on email plus IP address, so one corporate network does not starve its own users.
- A separate per-IP ceiling that caps fan-out abuse from a single host.
- Authentication endpoints fail closed: if the limiter cannot be evaluated, the request is rejected rather than waved through.
The same model backs the public API; see rate limits.
Layer 5 — Continuous anomaly detection
An automated detector scans authentication telemetry every five minutes for:
- Credential stuffing (many accounts attempted from one source)
- Password spraying (one password tried across many accounts)
- Velocity anomalies (sign-ins from multiple countries in a short window)
- Recovery-flow abuse (repeated reset attempts)
Detections currently run in alert mode: the security team is notified and investigates each finding.
Detection thresholds and response actions evolve over time. The detection categories above reflect production behavior as of the verification date.
What this means for your organization
- You do not need to bolt on perimeter controls to use The Quantum Club safely; the controls travel with the data.
- Enforce SSO and SCIM for your tenant so joiners and leavers are governed by your identity provider — see SCIM provisioning.
- Review the privacy and residency posture for where data lives and how it is encrypted.
You can name the five layers — passkey-first authentication, step-up, Row-Level Security, rate limiting, and anomaly detection — and explain why a failure in one does not compromise the others.