Why We Built Authentication Without Accounts, Passwords, or Personal Data

Most authentication systems start from the same assumption:
a user must have an account.

An email, a password, a profile, a database row with personal data.
Even when passwords are removed, the account usually stays.

We decided to question that assumption.

---

The problem we kept seeing

In many real scenarios, accounts are not the product:

• Event access (online or offline)
• One-time or short-lived sessions
• Admin or internal tools
• Temporary access for clients or partners
• Proof-of-presence or proof-of-control flows

Yet most auth solutions force you to:

• create users,
• store identifiers,
• manage recovery flows,
• and take responsibility for personal data you do not actually need.

This increases:

• legal surface (GDPR, breaches),
• engineering complexity,
• and cognitive load for users.

---

The idea: access without identity

We asked a simple question:

What if authentication was about proving access, not owning an account?

So instead of users, we work with access passes.

No usernames
No emails
No stored personal data

Only cryptographic proof.

---

How it works (high level)

The core flow is based on QR + TOTP, but with a different mental model:

1. A service generates a temporary access pass
2. The pass is represented as a QR code
3. The user scans it with any TOTP-compatible app
4. The server verifies the code cryptographically
5. Access is granted — no account involved

Key properties:

• The secret never leaves the user’s device
• The server stores only encrypted, non-PII data
• Passes can be short-lived, scoped, and revocable

From the server’s perspective, there is nothing to identify a person — only whether the proof is valid.

---

Why QR + TOTP?

We intentionally avoided:

• proprietary apps,
• magic links,
• phone numbers,
• biometric lock-ins.

TOTP is:

• widely supported,
• offline-friendly,
• well understood,
• easy to audit.

QR is:

• fast,
• cross-device,
• intuitive for non-technical users.

Together they allow a flow that is:

• simple for users,
• predictable for developers,
• and minimal in terms of data.

---

What this is not

This is not a replacement for:

• full user accounts,
• social login,
• identity management.

If you need:

• user profiles,
• long-term identity,
• personalization,
• social graphs,

traditional auth still makes sense.

This approach is for cases where identity is unnecessary overhead.

---

Why we are sharing this early

We are validating this approach publicly and carefully.

We are interested in:

• edge cases we might be missing,
• scenarios where this model breaks down,
• use cases where accounts are still unavoidable.

Feedback from engineers who have fought auth complexity in real systems is especially valuable.

---

Thanks for reading. Happy to discuss trade-offs, security considerations, and real-world constraints in the comments.

Comments

[Antón]

Thanks for reading.

This is not meant to replace identity-based auth, but to explore cases where identity becomes unnecessary overhead.

I am especially interested in edge cases where this model breaks down, or scenarios where accounts still turn out to be unavoidable in practice.

Happy to discuss trade-offs and real-world constraints.