Security
How REAL AUTH is built, and what it deliberately does not do
A security product should be legible. This page describes the choices that matter, including the ones that cost convenience.
No biometric data, anywhere
REAL AUTH never receives fingerprints, face templates, iris data, Face ID or Windows Hello material. Biometric verification happens inside the operating system and unlocks a key; the server sees a signature. There is no biometric database to breach because there is no biometric database.
Private keys never leave the device
Credentials are device-bound and, where the hardware supports it, non-exportable and protected by a secure element. REAL AUTH stores public keys and signature counters. It has no ability to sign on a user's behalf, which is a deliberate limit on its own power.
Approvals are bound to values, not to sessions
Every approval is tied to a deterministic encoding of exactly what was displayed. Changing an amount, an account number, a role or a domain produces a different fingerprint, so the earlier approval simply does not verify. Replay is detected because challenges are single-use and recorded server-side.
Sessions are server-side and revocable now
The cookie carries an opaque token; only its digest is stored. Sessions have both an idle timeout and an absolute lifetime, rotate on any privilege change, and can be revoked centrally. "Sign out everywhere" takes effect on the next request, not at the end of the attacker's session.
Passwords are supported, never recommended
Passwords exist for bootstrap, migration and limited recovery. They are hashed with Argon2id, and a password-only session is explicitly the weakest authentication level: it cannot authorise a sensitive action, and it cannot remove a passkey. A stolen password must not be enough to strip the stronger factor off an account.
Tenant isolation is enforced in the query layer
Every tenant-scoped record carries its customer, and isolation is applied where the data is fetched rather than in controllers where a single missed check leaks a table. There is a dedicated test suite whose only purpose is to attempt to cross that boundary.
Secrets are shown once and stored as digests
API secrets are displayed at creation and never again; the database keeps a hash plus a short prefix so a key can be recognised. Values that genuinely must be recoverable are encrypted with libsodium using a key held outside the web root. No cryptography is invented here — the primitives are standard and the libraries are maintained.
What REAL AUTH does not claim
It is not unhackable, it does not make fraud impossible, it does not detect deepfakes, and it does not prove that an account belongs to a legally verified human unless an identity check has actually been performed and recorded. It reduces specific, named risks. Any vendor telling you otherwise is selling something.
Read the disclosure policy
How to report a vulnerability, and how it will be handled.