Passwords are broken. This is not a hot take. Every security professional, every developer who has implemented auth, and every user who has clicked "Forgot Password" for the tenth time this month knows it.
The industry response has been a wave of alternatives: magic links, SMS codes, TOTP authenticators, and most recently, passkeys. Each one solves part of the problem while introducing new friction. Magic links depend on email delivery speed. SMS codes are vulnerable to SIM-swap attacks. TOTP apps require users to manually type rotating six-digit codes. Passkeys tie authentication to platform keystores that don't sync well across ecosystems.
The pattern is clear: every method works well in some contexts and fails in others. The answer is not to find the one perfect method. It is to build a platform that unifies multiple methods under one identity.
That is what we set out to build with QRAuth. It started as QR-based authentication. It is becoming an identity verification platform where QR is the primary -- but not the only -- transport.
How It Works
The flow is simple, and deliberately so.
A user opens a login page. The page displays a unique QR code. The user scans it with their phone camera -- no app install, no proprietary reader. The phone asks for confirmation -- biometric, PIN, or passkey, depending on how the developer configured it. Once confirmed, the browser session is authenticated instantly via SSE. Done.
If this sounds familiar, it should. WhatsApp Web, Telegram Desktop, and Signal Desktop all use a variation of this pattern. Billions of people already trust QR-based session authentication daily without thinking about it.
The difference is that QRAuth makes this available as a general-purpose authentication layer, not locked inside a single app.
The Security Model
Every QR code generated by QRAuth is cryptographically signed, single-use, and time-limited -- measured in seconds, not minutes. Each code is bound to a specific session. If nobody scans it before it expires, it is destroyed and replaced.
This means there is nothing persistent to leak. Unlike a password, API key, or even a session token, the QR code is ephemeral by design. A screenshot of a QR code is useless by the time someone tries to use it.
When a user scans the code, their phone does not simply confirm a session. It presents context: the requesting domain, timestamp, device information, and location. The user sees exactly what they are authorizing before they confirm. This makes QR authentication phishing-resistant in a way that most alternatives are not -- you cannot trick someone into confirming a session for evil-site.com when their phone clearly shows the requesting domain.
The phone itself acts as the authentication device. Think of it as a hardware security key that everyone already carries.
But a valid cryptographic challenge is only half the picture. The other half is knowing which device made the request and whether that device should be trusted. That is where the device registry comes in.
Device Trust: From "Valid Request" to "Known Device"
There is a critical difference between verifying that a request is cryptographically valid and verifying that it comes from a device you trust. Most authentication systems stop at the first. QRAuth is building toward the second.
The architecture already captures device data on every authentication event. The next layer -- currently in development -- exposes this as a user-facing device registry. Each user gets a list of their trusted devices: "iPhone Aris," "MacBook Office," "Pixel Personal." Devices can be named, reviewed, and revoked.
This changes the security model fundamentally. Instead of asking "is this challenge valid?" the system asks "is this challenge valid AND does it come from a device this user has previously registered and not revoked?"
The practical implications are significant. A stolen phone can be revoked from any other trusted device. A new device triggers a step-up verification before it is added to the trust list. An enterprise admin can enforce policies: only company-provisioned devices, only devices with biometric capability, only devices in specific geolocations.
This is the layer that turns authentication into identity management.
The Question Everyone Asks: Why Not Passkeys?
This is the first question every developer raises, and rightfully so. Passkeys are a strong technology with serious backing from Apple, Google, and Microsoft.
Here is an honest comparison.
Passkeys store credentials in platform keystores -- iCloud Keychain, Google Password Manager, Windows Hello. The protocol is open, and anyone can run their own WebAuthn server. But the keys live on the client side, inside platform ecosystems. This creates three practical problems.
First, cross-ecosystem portability is still fragmented. A passkey created on an iPhone and stored in iCloud Keychain is not seamlessly available on a Windows workstation. The sync story is improving, but it is not solved.
Second, shared and public devices are a problem. Walk into an office with shared PCs, a library with public terminals, or a hotel business center. Passkeys do not work well on devices that belong to someone else or to no one. There is no keystore to pull from.
Third -- and this is the part that does not get discussed enough -- when passkeys do handle cross-device authentication, the mechanism they use is a QR code. The FIDO Alliance's own cross-device authentication flow involves scanning a QR code with your phone to bootstrap the connection. QR-based authentication is not a competitor to passkeys. It is a layer that passkeys themselves rely on.
QRAuth is complementary, not competitive. The architecture includes a WebAuthn bridge that unifies QR and passkey authentication under the same identity. A developer does not choose between QR and passkeys. They offer both. The user chooses based on context. On their own laptop with a synced keystore, passkeys are the right choice. On a shared PC, a kiosk, a smart TV, or a colleague's machine, QR is faster and simpler. Either way, the identity is the same, the device trust model is the same, and the session management is the same.
This is the core architectural decision: QR is a transport, not the product. The product is a unified identity verification layer that happens to start with QR because it solves the widest range of contexts today.
Where QR Authentication Shines
The use case that generates the most immediate interest is shared device authentication.
Picture an office with ten shared workstations. Currently, each employee either has a local account with a password (credential sprawl), uses a shared account (security nightmare), or goes through an SSO flow that still requires typing credentials on a machine they do not own.
With QR authentication, the employee walks up to a workstation, scans the QR code on the login screen with their phone camera, confirms with a biometric tap, and the workstation loads their session with their permissions. No password typed on a shared keyboard. No credentials stored on the device. When they leave, the session ends.
This pattern extends naturally to kiosks, point-of-sale systems, smart TVs, digital signage, conference room displays, and any environment where typing credentials is either impractical or insecure.
Beyond digital authentication, QRAuth also handles physical QR verification. Any printed or displayed QR code can be cryptographically signed to prevent tampering, spoofing, or replacement. This addresses a growing problem in restaurants, parking systems, event ticketing, and product authentication where fraudulent QR codes redirect users to malicious destinations.
The Developer Experience
None of the above matters if integration is painful.
QRAuth ships stable SDKs for Node.js and Python today, with Go, PHP, Swift, and Kotlin on the roadmap. The target is under ten minutes from npm install to a working QR login. A generous free tier removes evaluation friction.
The architecture is straightforward. The developer creates a session, receives a QR payload, renders it, and listens for a webhook or WebSocket event when the user confirms. No redirect flows, no callback URLs, no OAuth dance. The simplicity is intentional -- authentication should be infrastructure, not a project.
The entire platform is open source. The SDKs, the protocol, and a reference implementation are available on GitHub. We are not asking anyone to trust a black box.
What We Are Building
QRAuth is early, and we are transparent about where we are in the journey.
What exists today: QR-based authentication with cryptographic verification, session management, SDKs for six languages, and a working developer experience. The core protocol is sound and battle-tested.
What is in active development: the device registry with user-facing management and revocation, the WebAuthn bridge for passkey unification, and the admin control plane with session visibility and audit trails.
What is on the roadmap: enterprise features (SSO, SCIM, policy engine), compliance certifications (SOC2, ISO 27001, GDPR documentation), and anomaly detection for risk-based authentication.
The direction is clear. We are not building a QR login widget. We are building an identity verification platform where QR is one method -- the one that happens to work everywhere today -- with passkeys, device trust, and policy controls converging under the same architecture.
The roadmap is shaped by what real developers tell us they need. We launched publicly this month and every conversation -- whether on GitHub, in developer communities, or in direct feedback -- makes the product sharper.
Try the demo at qrauth.io. Read the docs. Break it if you can. Tell us what is missing.
Top comments (0)