Desktop Flow

How authentication works when initiated from a desktop browser, and what to consider for security and UX.

Why Desktop Is Different

On mobile, the SDK can detect the user's operating system and device type from the user agent. On desktop, this information is not available upfront because the authentication will ultimately happen on the user's phone, not on the desktop browser. This means an extra step is needed before the user can complete the flow on their mobile device.

Desktop
OS Unknown
QR Code
Phone
Verified
Best Case

TS.43 via Chrome Digital Credentials (CTAP)

If the user's carrier and operating system combination supports TS.43, the Digital Credentials API can be invoked directly from the Chrome desktop browser. The browser communicates with the user's nearby Android device through a built-in proximity check, which provides an additional layer of security by confirming the phone is physically close to the desktop.

This is the most secure desktop path because it maintains the same cryptographic guarantees as the mobile TS.43 flow, with the added proximity verification.

QR Flow

When TS.43 Is Not Available

When TS.43 is not supported, the desktop flow relies on QR code scanning to hand off to the user's mobile device. By design, this decouples the authentication from the device that initiated the flow. The person scanning the QR and completing the carrier authentication on their phone may not necessarily be the same person sitting at the desktop.

For this reason, we recommend using non-TS.43 desktop flows for lower-risk use cases (such as login or account verification), and considering step-up verification for higher-risk actions like payments or sensitive account changes. Alternatively, you can guide the user to complete the entire flow on mobile, where the security model is tighter.

Security Consideration

For high-risk operations (payments, account recovery), consider adding step-up verification on top of the QR-based desktop flow, or redirect the user to complete the action on their mobile device directly.

SDK QR Code Configurations

The client SDK provides several configuration options for how the QR code modal is presented. Click any mode below to see the live modal. Use the theme toggle to preview light and dark modes.

If the user selects Android in pre-step mode and the carrier supports TS.43, the Digital Credentials API is triggered directly from the browser instead of showing a QR.

Theme:
Scan to Verify
iOS
Android

Pre-Step OS Selector

Choose OS first, then show the QR code.

Click to try live

Scan to Verify
iOS
Android

Dual QR Mode

Side-by-side QR codes for both platforms.

Click to try live

Scan to Verify
iOSAndroid

Toggle Mode

Single QR with iOS/Android toggle switch.

Click to try live

What Happens After Scanning

After the user scans the QR code, they land on a mobile verification page hosted on your domain.

Mobile Verification Page

Recommended

A web page hosted on your domain that the user lands on after scanning the QR code. It provides branded context about the authentication and explains what they are verifying and for which service, before triggering the carrier flow.

This is recommended because the user sees your brand, understands the purpose of the authentication, and is less likely to be tricked into completing a flow initiated by a fraudster on a different desktop.

Demo: Mobile Verification Page

We provide a reference implementation as a starting point. This demo shows the recommended flow and UX patterns, but we strongly recommend you build and host your own version under your domain, with your branding and your business logic.

View Demo

Tap the play button on the top left corner to start the flow.

Desktop State Preview

See all possible desktop-side states (success, failed, error) using our interactive preview:

Open Desktop State Preview

Summary

Desktop PathSecurity LevelBest For
TS.43 via Chrome (CTAP)High Proximity-verifiedAll use cases
QR + Mobile Verification PageMedium Branded contextLogin, account verification