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:
- A service generates a temporary access pass
- The pass is represented as a QR code
- The user scans it with any TOTP-compatible app
- The server verifies the code cryptographically
- 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.
Top comments (7)
So it works like this:
After a few days
That's OK, but does the user accumulate expired keys in the Auth application?
Thank you for raising this issue - it is a very important aspect of the system.
Short answer: yes, in the current model expired entries can accumulate in authenticator apps. Most TOTP apps do not support TTL-based cleanup, so this is a real limitation at the moment.
Conceptually, we see two paths going forward:
At this stage, the goal is to be transparent about the trade-offs rather than hide them.
Right now Toqen is still at the MVP stage. We deliberately started with the simplest and most interoperable setup (QR + standard TOTP apps) to validate the access model itself before shipping SDKs or deeper integrations.
That said, this limitation was anticipated early on. For the Beta v2.0 phase we are planning a dedicated auth application (Toqen Mobile) focused on instant entry, offline access, and smoother cross-device flows (outlined publicly on our roadmap)
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.
Because trust, privacy, and simplicity should not be optional.
Traditional authentication systems force users to create accounts, remember passwords, and share personal data—creating friction, security risks, and privacy concerns. We believed there was a better way.
So we built authentication that works without accounts, passwords, or personal data.
Most systems collect more data than they actually need. Emails, phone numbers, names—stored forever.
We chose a privacy-first approach.
If we don’t collect personal data, we can’t misuse it, lose it, or leak it.
Passwords are:
Hard to remember
Easy to reuse
Constantly breached
They are a security liability.
By removing passwords entirely, we eliminated one of the biggest attack surfaces in modern applications.
Account creation slows users down.
Forgot password flows frustrate users.
Verification emails break momentum.
Our approach lets users authenticate instantly, with no forms, no setup, no recovery steps.
Just access—when they need it.
Instead of relying on secrets users must remember, we use cryptographic and device-based trust mechanisms.
This means:
No password databases to hack
No personal identity to steal
No centralized user profiles to exploit
Security is built into the system, not layered on top.
Regulations are tightening.
Users are more privacy-aware.
Data breaches are costly and reputation-destroying.
Authentication without personal data is future-proof.
It aligns with zero-knowledge principles, data-minimization laws, and modern security expectations.
In Simple Terms
No accounts.
No passwords.
No personal data.
Just secure, private, and effortless authentication—the way it should have been from the start.
that's a really good solution, for this type of website that you wanna do a one time service.
Thank you, I appreciate your feedback.
I am also exploring how this model behaves outside of "one-off" use cases - such as recurring access without persistent accounts, or situations where continuity is needed without collecting identity.
If you have any examples where this would not work well, I would be genuinely happy to hear your thoughts.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.