Forem: Toqen.app

🚀 Toqen Mobile: access in 2 steps

Anton Minin Baranovskii — Fri, 03 Apr 2026 12:45:00 +0000

Your phone is already your access key

Your smartphone is almost always within reach.

To sign in to any service, you just tap Sign in and confirm access on your phone.

It does not matter whether you had access before.

Access is granted instantly, and the service determines what data is required for further interaction.

Wherever you are — laptop, shared computer, TV, or any other screen —

everything comes down to two actions:

Scan → Confirm

No extra steps.

No manual input.

One app — Toqen — becomes your universal access key.

📱 How it looks

QR scanning

The user opens the app and scans a QR code from the screen.

If the camera is unavailable, a code can be entered manually.

Access confirmation

The app displays:

service
login context
request expiration

All that remains is to confirm.

Access hub

All access entries are stored in one place:

active
archived
usage history

This is a single point of access control.

Services list

Select a service → tap Sign in → confirm access.

🔐 How it works under the hood

Each login is not a data transfer — it is an access confirmation.

scan QR
↓
challenge
↓
sign (device_private_key)
↓
verify on server
↓
access granted

What matters:

the QR contains only a temporary challenge
each request is single-use
the signature is created on the device
the server verifies it using the public key

🔑 Keys and security

The app uses a standard cryptographic model:

a key pair is generated (public / private)
the private key is stored in secure device storage
the public key is registered on the server
each login is a signed challenge

📌 Biometrics and device protection

Biometrics act as a local protection layer:

Face ID / Touch ID / Android Biometrics
device PIN
protected access to keys

In practice:

The device verifies the user locally
and then signs the request.

📎 Where passkeys fit in

It is important to be precise here:

Toqen follows the same core model as passkeys:

device-bound keys
challenge-response
no secret transmission

At the same time:

👉 passkeys are defined by standards like WebAuthn / FIDO2
👉 Toqen is an architecture that also supports QR-based flows and external screens

A correct way to describe it:

The architecture aligns with passkey principles and device-bound authentication.

⚡Why it is faster

Typical login:

enter username
enter password
confirm
recover if forgotten

Here:

2 actions

Scan → Confirm

📲 Availability

The app is available on Google Play in closed testing.

Join via form

Feedback

Direct access

Open to feedback and discussion.

Access-First Authentication in Production: Opening the Toqen.app Pilot Program

Anton Minin Baranovskii — Mon, 02 Mar 2026 10:42:25 +0000

Authentication is often discussed in terms of technologies — OAuth, passkeys, TOTP, SSO.

Much less attention is given to the architecture of access itself.

Toqen.app is designed as an access-first security layer — infrastructure that validates the right to enter a system at a specific moment in time.

After completing the first real-world integration in a live digital platform, we are opening a structured Pilot Program for teams interested in evaluating this model in production.

This integration operates within real user flows.

Why Production Validation Matters

Access mechanisms behave differently under real conditions.

In production environments, systems encounter:

repeated entries and session transitions
time-bound edge conditions
clock skew scenarios
traffic spikes
behavioral variance
interaction between UX and security constraints

Architecture assumptions are tested only when exposed to real users.

The goal of the pilot is to validate the access model under real operating conditions.

What Is Being Evaluated

The pilot focuses on:

context-aware entry validation
time-bound access logic
QR-initiated authentication flows
TOTP verification
replay resistance
abuse mitigation mechanisms
UX impact of access-layer decisions

The emphasis is on validating access events, not maintaining identity-centric state.

Integration Model

The pilot follows a structured process:

Review of the access scenario
Joint integration design
Deployment in production
Observation and analysis

The program is structured for teams operating:

SaaS platforms
content systems
educational environments
event or membership-based services

Participating teams may be publicly listed on the Pilot Partners page upon agreement.

Experience It Live

Access architecture reveals its characteristics only when interacting with real user traffic.

A limited number of pilot slots are available for teams interested in evaluating:

an access-first authentication model
architectural impact on UX
resilience and security in live environments

You can experience the production integration on Litseller.com.

Pilot applications are available via the Pilot Partners page on Toqen.app.

If you are exploring authentication as infrastructure rather than as a user database layer, this program is designed for real-world evaluation.

Why We Built Authentication Focused on Access, Not Identity

Anton Minin Baranovskii — Thu, 18 Dec 2025 01:38:52 +0000

Most authentication systems start from the same assumption:
authentication must start from a persistent user identity.

An email, a password, a profile, a database row tied to long-term identity.
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 long-term identity data you do not actually need.

This increases:

compliance and breach exposure (GDPR, incident impact),
engineering complexity,
and cognitive load for users.

The idea: access-first authentication

We asked a simple question:

What if authentication was about validating access, not managing identity?

So instead of users, we work with access passes.

No password-based login flows
No identity-centric user profiles
Identity data is minimized and contextual

Access is validated using 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 without relying on a traditional user account

Key properties:

The secret never leaves the user’s device
The server minimizes stored identity-related data
Passes can be short-lived, scoped, and revocable

From the server’s perspective, there is no identity-centric user profile to resolve — 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 identity surface area.

What this is not

This is not a replacement for:

identity-centric user account systems,
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-centric models become 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 identity-centric models remain 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.