DEV Community: A

I am currently open to new opportunities and collaboration

Tue, 28 Apr 2026 21:55:35 +0000

Apr 28

Open to Work and Collaboration

#career #webdev #softwareengineering #programming

1 min read

Why access-first auth matters?

Fri, 24 Apr 2026 11:01:05 +0000

In this article, I briefly explain why Toqen.app is built around an access-first authentication infrastructure.

1. Where fast access matters

There are scenarios where filling out forms gets in the way:

one-time website visits
Smart TVs
events and webinars
admin panels and systems where ownership must be confirmed frequently
systems where services, agents, or bots interact with each other

In these cases, email and passwords slow things down and increase risk.

Toqen.app provides access instantly through confirmation, without entering unnecessary data.

2. Access without unnecessary data

Instead of creating and managing accounts:

open the website
scan a QR code
confirm access

Access is confirmed at the moment of request, not stored in advance.

It does not matter where you are or what device you use everything happens in just a few steps.

3. Access control at the moment of use

With Toqen.app, every access can be:

confirmed
restricted
revoked

This gives control not only at login, but during actual usage.

4. Simple and predictable security

Most authentication issues come from human error:

forgotten passwords
password reuse
phishing
input mistakes

With Toqen.app:

no passwords to enter
no unnecessary steps
every access is confirmed on your device
device-bound cryptographic keys are used

This reduces mistakes and makes the process predictable.

Even in stressful situations, there is only one action confirm access.

It follows modern approaches similar to WebAuth, with a more straightforward user experience.

5. Less data, lower risk

Traditional systems store:

emails
passwords
tokens

With Toqen.app:

only data required for access is used
no unnecessary personal information is stored
each access request is single-use

This reduces the impact of mistakes and data leaks.

6. Simple and fast integration

For developers, speed of integration matters as much as security.

Toqen.app:

does not require complex setup
does not require identity-centric user profiles
allows collecting data required by business logic
integrates as an access layer on top of existing systems

This makes it possible to introduce secure access without redesigning the architecture.

Summary

Toqen.app is an approach where:

access is confirmed in real time
unnecessary data is not required
users stay in control
the system remains simple and clear

You do not remember access you confirm it when you need it.

P.S.

The app is available on the App Store. Closed testing on Google Play is ongoing message me if you want to try it.

The client app is open source, so you can review how access confirmation works and what data is actually used: https://github.com/toqenapp/mobile-react-native

Forgot your password again? QR Man is here to help.

Wed, 22 Apr 2026 13:14:31 +0000

Friend: "So, what’s this Toqen.app thing anyway? Just another password manager? I have everything saved in my browser, I’m good."

Me: "That’s the thing - it’s not. Browsers remember your passwords. Toqen.app makes them unnecessary."

Friend: "What do you mean 'unnecessary'? How am I supposed to log in? Magic?"

Me: "Think of it this way: a standard login is like a door with a cheap lock. Anyone with a copy of the key-your password-can walk right in. Toqen.app turns your smartphone into a universal digital key. You don’t have to type anything. You just walk up to the 'door' (open the website), scan a QR code, and your phone tells the site: 'Everything’s good, this is the owner, let him in.'"

Friend: "Wait, so I don’t have to remember anything? That sounds like a security nightmare. Okay, what if I’m sitting in a cafe and someone else tries to log in using my name from the other side of the world?"

Me: "That’s the main 'wow' effect. An attacker gets nowhere because there are no reusable credentials on the server. Unlike a password, which can be stolen and used again, the server only holds your public key. To log in, your phone creates a unique device signature for that specific moment. The server only verifies the signature - it never sees or stores your actual 'secret.' Even if someone intercepted the data, they couldn't use it to log in later. Your 'master key' stays physically on your phone and nowhere else."

Friend: "Right, but what if I lose my phone? Or worse, what if it gets stolen?"

Me: "That’s the key part. It’s like the keys to a modern car: no one else can even start the 'engine' without your specific biometrics. If you lose it, you restore access via a backup. It’s stored in an encrypted format that is mathematically impractical to crack without your master key. Meanwhile, your lost device remains useless to an intruder because it's protected by multiple layers of hardware-level security."

Friend: "So... it’s basically like FaceID for the entire internet?"

Me: "Exactly. It makes your digital life seamless. You move through websites like you’re walking through your own home, where all the doors open automatically as you approach. No stress, just access."

Toqen.app Mobile is Now Open Source

Wed, 22 Apr 2026 03:29:35 +0000

I have made the Toqen.app mobile application publicly available.

This is a deliberate decision to move toward transparency and independent technical review.

The mobile client is the part of the system that users directly interact with during authorization.

It is now open for inspection so anyone can verify how access is processed on the device.

What is Toqen

Toqen is an access-first authentication infrastructure designed for secure, real-time authorization.

Each access request is:

created in real time
explicitly approved by the user
cryptographically signed by the device
verified by the backend

The mobile app acts as a secure execution layer for these decisions.

What the open source mobile app actually does

The mobile client has a very narrow and well-defined responsibility:

scan or receive an access request
fetch request context from the backend
show the user what is being requested
collect explicit approval or denial
sign a short-lived challenge using a device key
send the signed result back for verification

The app does not grant access on its own.

All final decisions are verified by the server.

What data the app collects

This is the key point.

You can verify it directly in the code.

The mobile app stores only what is strictly required to perform cryptographic authorization:

device_private_key (generated on device, never leaves it)
device_id
app_instance_id

That is the full set of stored sensitive data.

There is no storage of:

passwords
session tokens
refresh tokens
reusable credentials
backend secrets

Sensitive data is stored using OS-level secure storage (Keychain / Keystore).

What is NOT inside the system

Toqen is built around strict data minimization.

QR codes do not contain secrets
authorization requests are short-lived
requests are single-use
no reusable tokens exist in the flow

Even if a QR code is intercepted, it cannot be used to gain access.

Authorization always requires:

user confirmation
device signature
backend verification

How authorization actually works

All flows follow the same pattern:
request → context → user decision → signature → verification → result

This guarantees:

no silent approvals
no implicit trust
no background authorization

Every access is intentional and verifiable.

Security model (short version)

The system assumes a hostile environment:

network is untrusted
QR codes can be intercepted
requests can be replayed

Security is achieved through:

device-bound cryptographic keys
challenge-response authorization
short-lived requests
server-side verification

Private keys never leave the device.

The backend never has access to them.

Why only the mobile app is open

The mobile client is the most critical part to verify from a trust perspective.

By open-sourcing it, I allow:

independent security review
verification of data handling
inspection of cryptographic flows
validation of what is and is not collected

The backend remains closed, but its behavior is fully defined through:

API contracts
documented flows
security model
threat model

This keeps the system verifiable without exposing operational infrastructure.

Build transparency

The build and release process is also documented.

Each build includes:

version
commit hash
tag
CI reference

This allows anyone to trace how a distributed app was produced.

What this means

You do not have to rely on claims.

You can:

inspect the code
verify storage behavior
review cryptographic operations
confirm data handling

The mobile app is fully transparent by design.

Repository

https://github.com/toqenapp/mobile-react-native

Product access:

iOS (App Store): search for “toqen.app”
Android (closed testing): https://forms.gle/f9FcbHyHJiajmFWV7

Typical use cases include:

SaaS platforms
gated digital content
memberships
online education environments
event access systems
other products requiring time-bound and policy-defined authorization

Building continues.

The Paradox: The More Secure the Product, the Less People Trust It

Tue, 14 Apr 2026 00:45:51 +0000

Over the past few days, early feedback on the Toqen mobile app has been coming in.

The reaction was not what you might expect.

Not curiosity.

Not technical questions.

But hesitation.

People are reluctant to install it.

First reaction defines everything

The moment a product is perceived as:

a password manager
a security tool
something that controls access

it is immediately placed into a high-risk mental category.

From there, the default response is simple:

“Better not touch it.”

This happens before any technical understanding.

Architecture is invisible

This is where things become interesting.

Toqen is designed around a few strict principles:

minimal data involvement
device-first trust model
no reliance on centralized sensitive storage

At a system level, this means:

cryptographic keys are generated on the device
secrets are not transmitted or stored centrally
access is verified through signed challenges

But none of this is visible to the user.

Architecture does not communicate itself.

Meanwhile, in other products

Users regularly:

share personal data
allow tracking
grant broad permissions

in applications that are perceived as:

social
entertainment
“harmless”

Even when those systems process significantly more data.

The asymmetry

This leads to a consistent pattern:

systems designed to protect are treated with suspicion
systems that collect data are treated with trust

Not because of their architecture.

But because of how they are perceived.

Trust is not a technical property

Security does not automatically produce trust.

Correct architecture does not automatically produce trust.

Trust depends on:

perception
clarity
predictability
ability to verify

Without these, even a strong system remains opaque.

What actually helps

If trust cannot be assumed, it must be built differently.

Not through statements.

Through verifiability.

One practical step is making the system inspectable.

The Toqen mobile app is being prepared for open source release.

This allows anyone to:

review how the system works
understand data flows
validate design decisions

Simplified flow (high level)

The authentication model is based on a challenge-response approach:

A login request is created (QR contains a temporary challenge)
The device scans the QR
The challenge is signed using a device private key
The server verifies the signature using the stored public key
Access is granted

Key properties:

no reusable tokens
no shared secrets in transit
short-lived challenges
device-bound authorization

Core principle

Data is involved only within the scope required to complete an access operation.

Critical elements:

are generated on the device
remain on the device
are never exposed in raw form

The server operates only as a verifier.

Better to see than to hear

There is a simple idea:

“Better to see once than hear a hundred times.”

Trust improves when systems can be explored directly.

The app is currently:

in testing on Google Play (access available on request)
available in release form on the App Store

Search: toqen.app

Final thought

Security alone is not enough.

If a system is not understandable, it will not be trusted.

The direction forward is clear:

build systems that are not only secure,

but also transparent, inspectable, and predictable.

Access-First Authentication with QR + Device Signatures

Mon, 13 Apr 2026 10:36:29 +0000

Toqen.app is now live on the App Store.

This is an attempt to rethink authentication from an access-first perspective: instead of managing identities and credentials, focus on granting access in real time, per request.

Why rethink authentication

Most systems still rely on reusable credentials:

passwords
session tokens
API keys

These introduce predictable problems:

credential leaks
replay attacks
uncontrolled sharing

Even with MFA, the core model remains static.

Core idea

Each access request should be:

short-lived
single-use
bound to a device
cryptographically verifiable

Instead of storing secrets, the system verifies a signed challenge.

Flow

User opens login page
↓
Server generates request
↓
QR code is displayed
↓
Mobile app scans QR
↓
User confirms access
↓
Device signs challenge
↓
Server verifies signature
↓
Access granted

QR format

QR does not contain secrets.

Example:

toqen://auth?request_id=91f2d&challenge=8fa92c1a&expires=1710000000

Properties:

expires in 30–60 seconds
single-use
cannot be replayed

Device model

On first launch:

device generates key pair
private key → stored in secure storage
public key → registered on server

Signing:

signature = sign(challenge, device_private_key)

Verification:

verify(signature, device_public_key)

Security properties

no reusable credentials
no secrets in QR
replay protection via TTL + single-use
device-bound authorization
server stores only public keys

Vault model

Sensitive data is encrypted client-side:

encrypted_vault
AES-256-GCM
vault_key stored in secure storage

Server never has decryption capability.

Where this fits

admin access
internal tools
high-risk operations
temporary access flows

Current status

iOS app is live on the App Store
Android version is in testing

Open for feedback

If you are working on authentication, security, or access control systems — feedback is welcome.

Contact: https://www.toqen.app/about#contacts

Android early access: https://forms.gle/f9FcbHyHJiajmFWV7

Building continues.

Access without passwords — short demo

Wed, 08 Apr 2026 06:15:55 +0000

Toqen.app mobile testing is now live on iOS

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.

Fri, 03 Apr 2026 14:08:42 +0000

A for Toqen.app

Apr 3

🚀 Toqen Mobile: access in 2 steps

#authentication #security #mobile #cryptography

2 min read

Instant Access for Users, Fast Integration for Developers

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

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

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.