Forem: Anton Minin Baranovskii

Access without passwords — short demo

Anton Minin Baranovskii — Wed, 08 Apr 2026 06:15:55 +0000

Toqen.app mobile testing is now live on iOS

Anton Minin Baranovskii — Tue, 07 Apr 2026 17:18:34 +0000

I am glad to share that Toqen.app mobile testing is now live on iOS.

If you would like to try how access-first authentication works in real usage before the official release, please fill out a short form and we will open access (link below).

For Android users, testing is already ongoing on Google Play.

Two scenarios are currently available:

Sign in via the mobile app — open the “Services” tab, tap “Sign in”, and you are you are instantly signed in in the browser
Sign in via QR — open Toqen.app or Litseller.com on your desktop, scan the QR code or enter the OTP in the app, and confirm access

The idea is simple: access is confirmed at the moment of login. No separation between sign up and login. The session is created securely and has a limited lifetime.

👉Join: https://forms.gle/5LhYEyj87aNLuKpN9

👉Honest feedback is highly appreciated: https://forms.gle/S7mmzji5ftGKZZys9

Hi everyone :wave: Have a great Friday! I have just released a mobile app - Toqen - now available in closed testing. The idea is simple: Scan Confirm Access.

Anton Minin Baranovskii — Fri, 03 Apr 2026 14:08:42 +0000

Anton Minin Baranovskii for Toqen.app

Apr 3

🚀 Toqen Mobile: access in 2 steps

#authentication #security #mobile #cryptography

Comments

2 min read

🚀 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.

The Age of Trust

Anton Minin Baranovskii — Fri, 13 Mar 2026 11:52:03 +0000

The Age of Trust

Why knowledge is no longer the main advantage in the AI era

Artificial intelligence has changed the value of knowledge.

For decades, professional evaluation was based on what a person knew: algorithms, frameworks, programming languages, and specific tools.

But when knowledge becomes instantly accessible, something else becomes scarce.

The ability to solve problems.

And something even more important.

Trust.

The World Has Changed

Artificial intelligence has become a vast encyclopedia available to everyone. It helps find information, accelerates learning, takes over part of routine work, and allows people to solve problems that previously required much more time.

This is already a new reality.

And in this reality, the way we evaluate people is beginning to change.

Knowledge Is No Longer the Scarce Resource

In the past, interviews often focused on what a person knew:

sorting algorithms
the syntax of a specific programming language
details of particular libraries

Today, such checks are gradually losing their meaning.

Knowledge is no longer scarce.

The scarce resource is the ability to ask the right questions and achieve results.

AI can help find almost any information.

However, it cannot replace a person who understands:

what problem needs to be solved
what questions need to be asked
how to verify the result
how to bring a solution to a practical outcome

This is what becomes a real professional skill.

The Shift in How We Evaluate People

The focus of evaluation must shift.

Not toward what a person already knows,

but toward how they solve problems right now.

A strong professional today is someone who:

can clearly formulate problems
can search for solutions
can verify results
can quickly master new tools

The Speed of Learning Has Changed

Learning speed has changed dramatically.

An experienced engineer can reach a production-ready level with a new technology within weeks. What once took months or years now happens much faster because information and tools are widely accessible.

Because of this, a person's past technology stack is no longer the main criterion.

Something else matters far more.

Trust

Whether this person can be trusted.

People tend to exaggerate experience, simplify the history of past projects, and sometimes adjust reality slightly in their favor. This happens in every industry.

Over time, a very simple set of factors comes to the forefront:

How a person solves problems
Whether they can be trusted

These two criteria become fundamental.

And this does not apply only to hiring.

It applies to:

teams
partnerships
communities
projects
any long-term interactions between people

Trust as Infrastructure

In a world where knowledge is available almost instantly, trust becomes the new infrastructure of interaction.

Recently, I have been thinking a lot about how trust could become more transparent and measurable in the digital world.

There are several ideas about how this could be implemented technologically. It is too early to reveal the details.

I am thinking about this project and will formulate the idea more clearly soon.

But one thing is already obvious.

In a world where knowledge is available almost instantly, what matters most is not what a person knows.

What matters most is whether they can be trusted.

To be continued.

Instant Access for Users, Fast Integration for Developers

Anton Minin Baranovskii — Sat, 07 Mar 2026 03:49:17 +0000

Access infrastructure often becomes one of the most complex parts of a product.

Over time this layer grows into a large subsystem that becomes increasingly difficult to modify safely.

At the same time every new product still needs a reliable way to provide access.

This leads to a practical engineering question:

How can access be implemented without building a large authentication system inside the product?

Toqen.app was designed with a simple goal:

Instant access for users
Fast integration for developers

Instead of implementing authentication infrastructure inside the product, the product connects to an access layer through a lightweight SDK.

From the product’s perspective the integration is intentionally minimal.

In most cases it requires only two things:

Install and connect the SDK
Store the minimal user record required by the product

Everything related to access infrastructure is handled by the access layer.

This means the product team does not need to implement:

login flows
session infrastructure
cryptographic verification
abuse-prevention mechanisms

In practice the basic integration typically takes around 10 minutes.

Development Mode

The SDK includes a development mode designed for extremely fast local setup.

In development environments the SDK runs with a built-in in-memory store.

This allows the access flow to work immediately without configuring any database.

Developers can start building product features right away while the access layer is already functioning.

Moving to Production

When the product is ready for production, the product stores its user data in its own database.

At this stage the product typically keeps a minimal user record such as:

an internal user identifier
product-specific data
optional profile information

The SDK documentation provides clear step-by-step guides for connecting existing databases without redesigning the product architecture.

What the Integration Looks Like

A simplified example might look like this:

npm install @toqenapp/sdk

import { createToqen } from "@toqenapp/sdk"

const toqen = createToqen({
  siteKey: "SITE_KEY",
  mode: "development",
  callbacks: {
    onLogin,
    onLogout
  }
})

app.use(toqen.middleware())

app.get(
  "/dashboard",
  toqen.authorize(),
  (req, res) => {
    res.send("Protected content")
  }
)

app.get(
  "/profile",
  toqen.authorize(),
  async (req, res) => {

    const user = await db.users.findById(req.toqen.userId)

    res.send(user)

  }
)

What the SDK Does

toqen.middleware()

checks the access cookie
validates the signature
decodes claims
adds the access context to req.toqen

toqen.authorize()

checks for valid access
returns 401 if access is not present

Reliability and Responsibility

The architecture separates responsibilities clearly.

Toqen.app handles

access infrastructure
access sessions
security mechanisms around access

The product handles

its own database
business logic
product functionality

Security updates and improvements to the access infrastructure are maintained by the Toqen.app platform.

This allows product teams to avoid maintaining complex authentication systems inside their own codebase.

Why This Matters

For engineering teams this means:

extremely fast initial integration
predictable architecture
less security-sensitive code inside the product
fewer infrastructure components to maintain

Teams can focus on building product functionality instead of maintaining authentication infrastructure.

Pilot Integrations

We are currently opening pilot integrations for Toqen.app.

The goal is simple:

demonstrate how access infrastructure can remain lightweight while still providing secure and reliable access.

If you are interested in exploring the approach or testing the integration in your environment, feel free to reach out.

Architectural Asymmetry in Authentication: Part 3 — Behavioral Automation and Phishing Efficiency

Anton Minin Baranovskii — Fri, 06 Mar 2026 18:06:32 +0000

In Part 1 we introduced the concept of architectural asymmetry in authentication.

In Part 2 we examined how disclosure before context creates structural exposure inside authentication flows.

This article explores another important effect of authentication architecture:

behavioral automation.

When authentication patterns repeat across services and over time, user behavior becomes automatic. That automation directly influences the effectiveness of phishing attacks.

The issue is not user awareness.

The issue is pattern conditioning created by system design.

How Authentication Patterns Become Automatic

Most authentication systems follow a familiar structure:
Page loads
→ User enters identifier
→ User enters secret
→ Access granted

This sequence appears across thousands of services.

Because the pattern repeats constantly, users begin executing it without conscious verification.

As this automation forms, several types of verification weaken:

domain verification
redirect origin awareness
interface inconsistency detection
unexpected authentication step recognition

The human brain optimizes repeated actions for speed.

Authentication becomes habitual interaction.

Cognitive Load and Time Pressure

Authentication often happens under time pressure.

Typical situations include:

internal systems accessed many times per day
consumer services opened quickly on mobile
short session lifetimes
frequent reauthentication policies

Under these conditions the mental model becomes simple:
Open page
→ complete expected steps
→ continue work

When a phishing page reproduces the expected pattern, the user’s cognitive system interprets the interaction as familiar.

The attack succeeds not because the user is careless.

It succeeds because the pattern matches expectation.

Why Phishing Pages Are So Effective

Phishing attacks rarely introduce new interaction models.

Instead attackers reproduce the exact interaction pattern users already know.

Typical phishing pages mimic:

login page layout
identifier input field
secret entry step
redirect flow

Because the interaction structure matches expectation, users often complete the process before deeper verification occurs.

The attack relies on behavioral predictability.

Transferable Secrets Amplify the Risk

Behavioral automation becomes far more dangerous when authentication relies on transferable secrets.

Examples include:

passwords
manually entered OTP codes
recovery codes
shared authentication factors

If a user enters such a secret into a phishing interface, the attacker can reuse it.

A behavioral mistake becomes persistent compromise.

Even short-lived secrets can be exploited if interception occurs within the valid window.

The combination of behavioral automation transferable secrets creates a highly efficient attack path.

Why Security Training Has Limited Effect

Security awareness training encourages users to:

verify domains
avoid suspicious links
check login pages carefully

This helps.

But training competes with a powerful opposing force:

habit formation.

When users repeat the same authentication pattern dozens of times per day, automatic behavior dominates.

Even well-trained users may act automatically when:

they are under time pressure
the interface looks familiar
the expected login pattern appears

Education improves resilience.

It does not eliminate behavioral conditioning created by authentication architecture.

Breaking the Behavioral Pattern

Reducing phishing efficiency requires weakening predictable authentication patterns.

Several architectural approaches help achieve this.

Device-Bound Confirmation

Authentication tied to a device rather than manual secret entry.

Challenge-Response Authentication

User confirmation occurs in a trusted environment rather than inside the requesting page.

Out-of-Band Verification

Confirmation happens through a separate trusted channel.

Cryptographic Authenticators

Hardware-backed keys and passkeys replace typed secrets.

The key principle remains the same:

confirmation happens in a trusted context, not inside the requesting interface

This significantly reduces the impact of page imitation.

Context Changes the Pattern

When authentication begins with context validation rather than identifier disclosure, the interaction model changes.

Instead of repeated manual steps, confirmation becomes tied to:

device possession
session continuity
cryptographic challenge
trusted environment signals

Users perform less repetitive secret entry.

Behavioral automation weakens.

Attackers can no longer rely on a universal login pattern being executed automatically.

Architectural Implication

Authentication security depends not only on cryptography and protocols, but also on behavioral patterns created by system design.

Identity-first systems encourage repeated disclosure of identifiers and secrets.

Over time this produces a stable loop:
open page
→ disclose
→ proceed

Attackers exploit the predictability of this loop.

Architectural changes that reduce repeated secret entry and bind confirmation to trusted contexts weaken this predictability.

This does not eliminate phishing entirely.

But it changes the economics of the attack.

Looking Ahead

Authentication systems are gradually moving toward models where:

manual secret entry becomes rare
confirmation is device-bound
session context influences authentication decisions
disclosure happens only when strictly necessary

These changes reduce both compromise scale and behavioral exploitation.

The shift is gradual, but the architectural direction is becoming clearer.

In Part 4, we will examine how transferable secrets amplify compromise scale and why reducing their role fundamentally changes the attack surface of authentication systems.

Where AI Will Not Replace Humans Anytime Soon

Anton Minin Baranovskii — Fri, 06 Mar 2026 07:47:53 +0000

If AI ever “takes over the world”, it probably will not happen with weapons.

It will happen much more quietly — by gradually taking over human work.

We are already seeing this shift.

AI tools are replacing many routine tasks across industries. But the impact is not uniform. Some professions are changing rapidly, while others remain far more resistant to automation.

Here are a few areas where humans are likely to remain essential for a long time.

1. Physical Repair and Service

The real world is messy.

Unlike software systems, physical environments are rarely predictable or standardized.

Every repair job can involve:

different equipment
unexpected failures
incomplete documentation
unique environmental conditions

A mechanic repairing an engine or an electrician troubleshooting wiring constantly deals with situations that cannot easily be reduced to structured data.

Robotics will eventually improve, but deploying adaptable machines capable of handling this complexity at scale is still far away.

For now, humans remain far better at solving problems in unpredictable environments.

2. B2B Sales

Enterprise sales are not just about presenting information.

They are about:

trust
negotiation
relationships
timing

AI can already help generate emails, proposals, and reports.

But closing a complex deal still depends heavily on human interaction and trust.

Large contracts often involve informal communication, subtle signals during negotiations, and long-term relationship building.

AI will become a powerful assistant in sales workflows, but replacing human sales professionals entirely is unlikely anytime soon.

3. Software Engineering

AI is already transforming how code is written.

Tools like AI coding assistants can generate code, suggest fixes, write tests, and even scaffold entire services.

This significantly impacts routine development tasks.

In particular:

junior-level tasks are increasingly automated
many middle-level tasks are becoming easier with AI

However, higher-level engineering work remains difficult to automate:

system architecture
large-scale system design
complex integrations
engineering trade-offs

The role of developers is shifting.

Less time writing boilerplate code.

More time designing systems and making architectural decisions.

The real value of developers increasingly comes from system thinking rather than typing code.

4. DevOps and Infrastructure

Production systems rarely behave like clean diagrams in documentation.

Real infrastructure often includes:

legacy systems
unusual configurations
partial documentation
unexpected operational failures

When a system goes down at 3 AM, solving the problem usually requires experience, judgment, and the ability to understand complex system behavior quickly.

AI tools can help analyze logs and suggest solutions.

But responsibility for diagnosing and fixing incidents still falls on experienced engineers.

5. Cybersecurity

Cybersecurity is fundamentally different from many other technical fields.

It is not just about solving technical problems.

It is about defending systems against intelligent adversaries.

Attackers constantly change tactics, adapt tools, and search for new weaknesses.

AI will certainly help automate:

threat detection
log analysis
vulnerability discovery

But security ultimately remains a strategic battle between humans.

As long as attackers continue to innovate, human expertise will remain essential.

The Bigger Shift

AI is not simply replacing professions.

It is reshaping them.

Routine and predictable tasks are increasingly automated, while the remaining work shifts toward:

system thinking
responsibility and decision-making
working with uncertainty
operating in complex real-world environments

In many fields, the future will not be humans vs AI.

It will be humans working with increasingly powerful tools — focusing on the parts of the problem that machines still struggle to solve.

If you want to explore these ideas further — especially system thinking, decision-making under uncertainty, and working in complex environments — these books are worth reading.

Thinking in Systems — Donella Meadows

A foundational book about how complex systems behave and how feedback loops shape real-world outcomes.

Superforecasting — Philip Tetlock

A deep dive into how people can make better predictions and decisions in uncertain environments.

Skin in the Game — Nassim Nicholas Taleb

A powerful perspective on responsibility, risk, and why decision-makers must face the consequences of their choices.

Range — David Epstein

An argument for broad thinking and interdisciplinary knowledge in a world that increasingly rewards adaptability.

Short summaries of these books are available on https://litseller.com if you want to quickly understand their core ideas before deciding whether to read the full book.

Telegram and the Architectural Shift Toward Access-Layer Authentication

Anton Minin Baranovskii — Tue, 03 Mar 2026 19:21:40 +0000

Telegram has introduced a new OpenID Connect-based implementation of Log In with Telegram, aligning its authentication flow with standardized OIDC practices.

Architecturally, it reflects a broader shift: authentication is increasingly designed as a structured access layer within digital systems.

Protocol-Driven Access

With OIDC in place, access is formalized through:

Authorization Code Flow
PKCE
ID tokens
Signature verification
Issuer and audience validation
Strict redirect_uri control

The login process becomes a standardized protocol for negotiating access between client, browser, and server.

From Identity-Centric to Access-Centric Design

Traditional authentication systems centered around identity storage:

User accounts
Profile attributes
Credential verification
Password recovery

Modern architectures increasingly center around access control:

When is access granted?
Under which scope?
For how long?
Under what validation guarantees?

Identity remains part of the system.

Access becomes the architectural focus.

Access as a Dedicated Layer

When authentication is implemented through OIDC + PKCE, attention shifts toward:

Session issuance
Token lifecycle
Scope definition
Cryptographic validation
Lifetime enforcement

This defines an access layer — a component responsible for governing how access is negotiated, issued, and validated.

Such a layer integrates cleanly with existing authentication stacks and access management systems.

Trusted Client Confirmation

Telegram’s flow includes confirmation inside the application itself.

Architecturally, this:

Binds the browser session to an authenticated client
Moves confirmation into a trusted environment
Reduces exposure to phishing-style credential capture

Session binding becomes part of the access architecture.

Scoped and Contextual Access

Use of scopes (e.g., phone sharing, communication permissions) structures access as a defined set of rights.

This model introduces:

Explicit permission negotiation
Context-bound access
Clearly defined capability boundaries

Authorization becomes a controlled issuance of rights with defined parameters.

Architectural Direction

Standardized, protocol-driven authentication models point toward a clear architectural direction:

Access mechanisms are formalized
Login flows are protocolized
Session issuance is cryptographically verifiable
Access control is treated as infrastructure

Authentication increasingly functions as a dedicated access layer within system design.

Telegram represents one example of this broader architectural evolution.

Access-layer design is becoming a norm rather than an exception in modern digital systems.

After the AI Boom Comes the Engineering Correction

Anton Minin Baranovskii — Tue, 03 Mar 2026 04:01:37 +0000

Software history does not move linearly.

It moves in cycles.

Every major wave of automation follows a similar structural pattern:

Acceleration
Mass adoption
Complexity explosion
Operational cost growth
Engineering stabilization

AI-generated code is not a disruption of this pattern.

It is the latest iteration.

This article is not about whether AI will replace developers.

It is about how automation repeatedly shifts complexity rather than removing it.

The Recurring Pattern in Software History

1️⃣ WordPress and the Democratization Wave (2008–2014)

In 2011, WordPress powered ~8% of all websites.

By 2014, that number reached ~20%.

Today it exceeds 40% (W3Techs).

The narrative at the time:

Build websites without developers
Fast deployment
Massive plugin ecosystem

The structural result:

Plugin conflicts
Update instability
Security surface expansion
Performance degradation from heavy themes

A secondary market emerged:

Security audits
Performance refactoring
Migration to custom stacks

Acceleration created architectural debt.

Debt created demand for engineers.

2️⃣ Low-Code / No-Code Expansion (2015–2020)

Gartner reported >20% CAGR in low-code platforms during the mid-2010s.

The promise:

Business teams build their own tools
MVP in days
Reduced dependency on engineering

What happened at scale:

Integration constraints
Custom logic bottlenecks
Vendor lock-in
Scaling limitations

Low-code reduced the cost of starting.

It did not reduce the cost of growing.

3️⃣ Microservices Hyper-Expansion (2015–2020)

After public architecture disclosures from Netflix and Amazon, microservices became aspirational architecture.

Even small teams adopted:

Distributed services
Kubernetes
Service meshes
Complex CI/CD pipelines

CNCF surveys show Kubernetes adoption accelerating sharply after 2017, reaching broad enterprise usage by the early 2020s.

Then reality appeared:

Operational overhead
DevOps team expansion
Observability complexity
Distributed failure modes
Network latency accumulation

A counter-movement emerged:

Modular monoliths
Infrastructure simplification
Service consolidation

Again:

Acceleration → Complexity → Correction

The AI Code Phase (2023–…)

GitHub reports indicate that a significant portion of new code is now written with AI assistance.

In some surveys, over 40% of new code involves AI tools.

What AI improves:

Boilerplate generation
CRUD scaffolding
Test generation
Rapid prototyping
Documentation drafting

What AI does not solve:

Cohesive system architecture
Long-term maintainability
Evolutionary design
Scaling trade-offs
Operational simplicity

AI generates functions.

It does not carry responsibility for system evolution.

The Structural Shift

AI lowers the cost of writing code.

It does not lower the cost of:

Maintaining code
Refactoring systems
Scaling infrastructure
Integrating with external systems
Reducing architectural entropy

Complexity does not disappear.

It relocates.

From creation

to operation.

The 5-Phase Automation Model

Across waves, the pattern remains consistent:

Phase 1 – Acceleration (2–4 years)

New tooling dramatically increases output velocity.

Phase 2 – Mass Adoption

Barriers fall. System count explodes.

Phase 3 – Architectural Debt Accumulation

Inconsistent patterns emerge. Redundancy grows.

Phase 4 – Operational Cost Expansion

Maintenance outpaces development cost.

Phase 5 – Engineering Stabilization

Demand shifts toward simplification and structural redesign.

AI is currently in Phase 2.

What Will Likely Happen Next

Based on previous cycles:

2023–2026 → AI-driven rapid generation

2026–2030 → Structural cleanup and consolidation

This is not collapse.

It is correction.

Who Becomes Critical in the Stabilization Phase

Not “people who can write code.”

But engineers who can:

Read large unfamiliar codebases
Identify redundancy
Remove unnecessary abstraction layers
Collapse over-engineered systems
Redesign for scale
Reduce operational surface area

The scarce skill is not typing speed.

It is system-level simplification under real-world constraints.

A Technical Observation About AI-Generated Code

AI tends to produce:

Defensive over-abstraction
Pattern repetition
Verbose indirection
Excessive optionality
Generic solutions where specificity would be simpler

This is rational behavior for probabilistic generation.

It is not optimal behavior for long-term systems.

Entropy increases quietly.

Automation first lowers entry barriers.

Later, it raises the value of expertise.

Software history does not show engineers disappearing.

It shows engineers becoming more necessary during stabilization.

We are in the acceleration phase.

Stabilization is structurally inevitable.

And it will require engineers who design systems — not just generate code.

Pilot Program is open. Access-first authentication in production.

Anton Minin Baranovskii — Tue, 03 Mar 2026 00:42:07 +0000

Anton Minin Baranovskii for Toqen.app

Mar 2

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

#authentication #security #architecture #webdev

Comments

2 min read

What is so complicated about authentication? Connected, configured, launched, everything works. Then why is there so much discussion around it?

Anton Minin Baranovskii — Tue, 03 Mar 2026 00:40:55 +0000

Anton Minin Baranovskii

Mar 2

Seriously? What’s So Hard About Authentication?

#authentication #security #architecture #webdev

Comments

2 min read