DEV Community

vdelitz
vdelitz

Posted on • Originally published at corbado.com

QR Login Failure: Why QR Code Login Breaks

#webdev #security

QR login is a cross-device flow, not one click

QR code login looks clean in a demo. Show a code on desktop, scan it with a phone, confirm, done.

In production, it is much messier. The article “QR Login Failure: Why QR Code Login Breaks” maps out why a simple-looking QR flow often fails across scan, handoff, proximity check, confirmation, or callback. That is the core problem with debugging QR code login not working: most teams only see the final outcome, not the failing step.

This gets worse in passkey QR code login with WebAuthn cross-device authentication (CDA). Once the browser and operating system take over, the relying party usually sees only coarse ceremony outcomes like success, error, timeout, or server verification result. The hidden middle is where the real failure often lives.

Not all QR login flows fail the same way

A useful distinction from the source material is that there are really two different flows people call “QR login.”

Flow type What the team can usually observe Main blind spots
Custom QR login QR shown, scan, app open, confirmation, callback Wrong app routing, wrong account, abandoned confirmation
WebAuthn CDA passkey QR flow Ceremony start, completion/failure, timeout, verification result QR scan success, Bluetooth proximity check passkeys, phone-side prompts

That distinction matters because instrumentation strategy changes completely.

In a custom flow, you can often track almost every step directly. In WebAuthn CDA, you cannot honestly claim direct visibility into scan or proximity unless your own app or SDK exposes it. You have to separate observed facts from inferred phases.

That sounds subtle, but it is the difference between useful authentication observability and hand-wavy dashboards.

The boring failures are the real failures

QR login failure is usually not caused by some exotic cryptographic edge case. It is usually a chain of small, very human problems.

Typical examples from the source:

  • the QR code is visible but hard to scan on a dim screen or kiosk
  • the user scans with the default camera app when the flow expected a specific app
  • the wrong phone, work profile, or account handles the challenge
  • Bluetooth or network restrictions break CDA proximity checks
  • the user confirms on mobile, but the desktop never gets the final callback
  • the desktop just spins, so support hears “QR login not working”

That is why QR login conversion rate can look acceptable in a demo and brittle in production. Demos control screen quality, lighting, network conditions, and device state. Real users do not.

Debugging QR login issues needs a stitched funnel

Most analytics setups are too shallow for this problem. They record “clicked sign in with QR” and maybe “login success.” Everything that matters sits in between.

A better model is an authentication analytics login funnel stitched across desktop and mobile.

For custom QR login, the article recommends tracking steps like:

  1. QR code shown
  2. QR code scanned
  3. Mobile session opened
  4. Confirmation shown
  5. Confirmation completed
  6. Desktop callback received
  7. Session established

For WebAuthn CDA, the observable events are different:

passkey ceremony started
challenge created
WebAuthn call completed or failed
error name
timeout
elapsed duration
server verification result
session established
Enter fullscreen mode Exit fullscreen mode

That still does not expose every phone-side step, but it gives you enough structure to infer where failures cluster.

Segmentation is where root causes appear

Once events are stitched, the next step is segmentation. This is where vague support complaints turn into patterns.

You want to compare:

  • custom app QR vs passkey QR vs other QR-based login methods
  • iOS vs Android
  • desktop browser differences
  • app versions and mobile browser behavior
  • abandonment vs technical failure

That last split is especially important. A user walking away from a QR screen and a Bluetooth timeout both hurt conversion, but they are not the same problem and should not get the same fix.

Corbado is a passkey observability and adoption platform for large B2C enterprises. The useful idea here is not the product name, though. It is the operating model: connect desktop start, browser or app events, server verification, and final session outcome into one journey.

If you only measure final success, every QR login failure looks identical. If you instrument the missing middle, you can finally tell whether the issue is scan quality, app handoff, WebAuthn timeout, callback failure, or user confusion.

Read the full breakdown.

Top comments (0)