WebAuthn Cross-Device-Authentication: Passkeys via Mobile-First Strategy

1. Introduction: CDA-First Pattern

2. Why Does a CDA-First Approach Make Sense?

3. What is a CDA-First Pattern?

4. Benefits of CDA-First Pattern

       4.1 Universal Access on Any Device

           4.1.1 High WebAuthn Availability on Devices without Platform Authenticator

           4.1.2 Facilitated Location-Independent Access

       4.2 Enhanced Security Compared to Traditional Auth Methods on Smartphones

5. Disadvantages of CDA-First Pattern

       5.1 Smartphone Dependence

       5.2 Mixture of Work and Private Context

       5.3 Redundancy on Passkey-Ready Desktops (mainly macOS)

       5.4 Dependence on Bluetooth Availability

       5.5 CDA Can Behave Unexpectedly on Different Operating Systems & Browsers

6. User Experience of CDA-First Pattern

       6.1 CDA-First Sign-Up Process

           6.1.1 CDA-First Sign-Up on a Smartphone

           6.1.2 CDA-First Sign-Up on a Desktop

       6.2 CDA-First Login Process

           6.2.1 CDA-First Login on a Smartphone

           6.2.2 CDA-First Login on a Desktop

7. Technical Implications of CDA-First Pattern

       7.1 CDA-First Recovery Process

       7.2 PublicKeyCredentialHints as the Future for CDA-First Patterns

       7.3 CDA-First PublicKeyCredentialCreationOptions

       7.4 CDA-First PublicKeyCredentialRequestOptions

8. Conclusion: Outlook

9. Evaluation

Passkeys are gaining more and more traction with the rollout at large digital companies such as Binance, Revolut or Vercel. Yet, the journey towards a universally passkey-ready ecosystem presents some challenges, particularly when the users of an app or website have diverse device environments.

This disparity in passkey-readiness, especially in older Windows 10 desktop PCs (this problem on Windows machines applies especially until Windows 10 disappears and Microsoft activates passkey synchronization via a Microsoft account), certain Linux, and ChromeOS laptops, poses a considerable obstacle for developers and product managers aiming to implement seamless, secure authentication systems. However, as of April 2024, ChromeOS has only a market share of 2.27% and Linux 4.05% globally. These numbers should be even lower for regular consumers.

Not all devices offer the same level of support for passkeys, leading to synchronization and recovery issues, especially on devices that create only single-device passkeys. Moreover, the absence of cross-platform passkey management solutions from the operating system amplifies these challenges, making it difficult for users to maintain access across multiple devices and platforms.

In this blog post, we want to provide an alternative approach of employing passkeys to the userbase that we call the CDA-first approach (CDA = Cross-Device Authentication). Alternative naming is "mobile-first passkey authentication" or "mobile-first CDA". See this blog post for more technical insights into the functionality of cross-device authentication in WebAuthn.

Before we start, we have to admit: in the beginning of our passkeys journey, we were suspicious about CDA. Bluetooth always seemed like a UX nightmare, as it can be unstable causing frustrations for users. However, we have been witnessing that most people are familiar with Bluetooth and issues don't occur as often as expected. Moreover, QR code scanning has been present in most people's live for years. This makes this analysis even more interesting.

At first, we need to understand how the standard passkey register and authentication flow works. You need to understand that if platform authenticators are involved, the client always searches the device for availability of Face ID, Touch ID, Windows Hello etc.

If available, the passkey flow starts immediately to create a / log in with a passkey. If the device is not passkey-ready, then the flow does not start and an error message is displayed, so the user has to use alternative forms of logins. This is a rather suboptimal user experience and creates the motivation to come up with an alternative solution.

Additionally, we have seen from data about passkey-readiness, that most Android and iOS devices are passkey-ready and create synced passkeys (see the latest data in State of Passkeys). Thus, it makes having a solution centered around mobile devices (mobile-first CDA) an interesting idea.

The motivation for a CDA-first approach can be broken down into four aspects:

• Passkey Synchronization and Recovery Challenges of Desktops: Some desktops that support passkeys lack the capability for cross-device / cross-platform synchronization and recovery. This is the case on devices running Windows (currently) as well as Linux and ChromeOS devices. In case you lose any of these devices, or want to access your account from another device, the process to regain access to your account is cumbersome, as passkeys created on these devices are mostly single-device passkeys (device-bound passkeys).

• Smartphones are Universally Available: Nearly everyone nowadays owns a smartphone, and both iOS and Android devices show near-universal passkey-readiness, with most passkeys being synchronized.

• Users are Familiar with QR Codes: Since the COVID pandemic, most people – even non-technical folks – are familiar with QR codes. They know how to scan them and what to expect after a successful scan. Together with the fact, that basically no one leaves their house without a smartphone, which serves as the QR code scanner, makes the case compelling.
• Standard Local Passkeys Don't Offer a Secure Fallback: One of the core challenges in implementing passkeys is offering a secure fallback method, particularly when passkeys (via a platform authenticator) are either not working or unavailable on a device. A viable solution could be to provide a secure fallback through CDA (CDA as fallback) for all authentication processes that are either aborted, cancelled, or fail. This approach would enable the use of CDA on a Windows 10 machine with Chrome (as Chrome supports CDA) and on all devices with Windows 11 (all Windows 11 devices are equipped with a platform authenticator). Therefore, allowing alternative methods, such as the standard single-device passkey login on a Windows device, while concurrently having a smartphone equipped with a passkey that could be utilized for CDA, appears to be an effective strategy (same applies to ChromeOS and Linux).

Given the current situation, leveraging smartphones for passkey generation and management seems like a compelling solution. This approach effectively circumvents the limitations of less-equipped desktop devices and takes full advantage of the widespread of smartphones.

After understanding the situation and problems of current (mostly) desktop devices and their single-device passkey capability, we need to see what requirements such a concept which employs CDA-first authentication, should have. We summarize all aspects in the following four requirements (RQ):

• RQ1 Smartphone as Central Passkey-Holding Device: The smartphone holds the primary passkey, ensuring security and ease of access for all devices that the user wants to access. This means the smartphone is used to access services on the smartphone itself but also on other (desktop) devices.
• RQ2 Desktop Passkey Creation is Optional: On desktops, users are encouraged to use their smartphone-stored passkey. Adding a new passkey on the desktop is considered a secondary option. However, the passkey on a mobile device is always required before (mobile-first CDA).
• RQ3 CDA Flows before Local Platform Authentication Flows: The system prioritizes CDA flows over local platform authentication flows. This means that e.g. even if a single-device passkey exists for a Windows desktop, the connected smartphone's passkey will be tried for login at first. Only if the user manually selects to use the single-device passkey of Windows, this single-device passkey will be used.
• RQ4 Use WebAuthn Standard QR Codes Instead of Custom Solutions: Even though, there is the possibility to introduce proprietary solutions leveraging QR codes for cross-device authentication, we want to make use of WebAuthn's standard QR codes and Bluetooth proximity check as often as possible.

Become part of our Passkeys Community for updates and support.

Join

Now that we've been formulating the requirements for a CDA-first solution, let's briefly discuss the benefits this system brings to the table.

Accessing a service from a non-passkey-ready device becomes less of an issue, as the smartphone facilitates access.

Passkey-readiness, particularly the passkey syncing capabilities missing in Windows 10 (or Windows in general), can be addressed. Most Windows devices (over 99%) support WebAuthn, enabling a CDA flow – even in the absence of fingerprint / face scanners or a TPM. The primary complication arises with devices lacking Bluetooth capabilities. In such instances, a proprietary QR code solution, which does not rely on Bluetooth, could be a solution.

There are services where people often create an account on a desktop but then primarily access the service via a web app on a smartphone, or directly through the native iOS / Android app (e.g., flight passengers may book their ticket on a desktop but access the boarding passes on their smartphone). These businesses tend to have a significantly higher usage rate on native apps or mobile platforms compared to desktop. In such scenarios, customers benefit from having their passkeys readily available and not bound to non-synced, stationary desktops at home.

The smartphone acts as a secure token, akin to a hardware security key, but with the added advantage of being more universally accessible and user-friendly. Compared to other popular mobile login methods, such as passwords, SMS OTP or social logins, passkeys are more secure and privacy-friendly. Also for the relying parties, it's way cheaper to use passkeys compared to e.g. SMS OTPs.

Users in 2024 do not leave their house without their smartphones and also since the COVID pandemic most people are more than used to scan QR codes. Together, with the fact that the majority of people just use their biometrics to unlock their smartphones (and desktop machines), this solution just bets on existing user behavior which should facilitate the general acceptance and adoption of a CDA-first authentication flow.

Subscribe to our Passkeys Substack for the latest news, insights and strategies.

Subscribe

There are not only advantages of the proposed system, so let's have a look at potential disadvantages.

First of all, users must have a smartphone to utilize the CDA-first authentication strategy, even though they might only want to authenticate on a desktop. The magnitude of this disadvantage is to be discussed as in general more people have a smartphone than a desktop.

Users wouldn't want to have a passkey on their private smartphone (in a bring-your-own-device scenario) while trying to authenticate to business applications. Also IT admins, could not want this authentication strategy, as private devices could be lost and keys would be synced in private cloud accounts (e.g. the user's private iCloud Keychain) or private third-party password managers (e.g. the user's private Dashlane account).

For desktop devices that are already passkey-ready, this adds an extra step, although exceptions can be made for synced desktops, such as on macOS, to retain their direct passkey use capability. Moreover, Post-CDA Passkey Creation could be suitable in these cases.

For standard WebAuthn CDA functionality, both the CDA authenticator (smartphone) and the CDA client (desktop) must have Bluetooth capability. However, older desktop machines may lack this feature. In such cases, resorting to a proprietary QR code solution could be a viable alternative.

Different combinations of operating systems, browsers, and their respective versions can lead to unexpected behavior, such as users being prompted with QR codes when they are not anticipated, lack a passkey on their smartphone, or are unable to log in for other reasons. This necessitates enhanced system intelligence to prevent user frustration. Thus, CDA should be implemented carefully to ensure user safety and minimize unexpected QR code prompts. We call this contextual CDA activation.

Let's examine how the different processes of CDA-first pattern look like from a UX perspective. Some UX improvements have been introduced over the past months by the browser and operating system providers.

One example can be seen in the following screenshot. Here, in Chrome 123 on a Windows 11 machine, the browser remembers the name of the smartphone that has been used for CDA on this desktop (smartphone "SM-G991B"). Automatically, all available passkeys on this smartphone ("SM-G991B") are shown in the WebAuthn login modal along with the smartphone's name to streamline the passkey login.

Another UX improvement, can be seen in the following screenshot. Here, a CDA client tries to remember the CDA authenticator, so that future QR scans can be skipped facilitating future CDA login processes.

Let's now have a closer look at different process flows.

In general, users create their passkey on their smartphone, which then becomes the passkey to their account – independent of used device.

Based on the State of Passkeys data, we assume that almost all smartphones are passkey-ready, so the sign-up flow on smartphones is the regular WebAuthn register flow.

The sign-up on desktop devices is different to the standard WebAuthn register flow. After the user provided a login identifier (e.g. email address, phone number, user name), the system must detect that it's a desktop that tries to create the account / create the passkey. Here, the system's logic must prevent the start of the standard WebAuthn register flow. Instead the cross-device authentication flow should start by displaying a QR code that the user should scan with their smartphone. The passkey should then be created on the smartphone, while access to the service is granted on the desktop.

Optional: if the desktop is passkey-ready (a platform authenticator is available), there should be a popup asking the user to create another passkey with the desktop's platform authenticator. Consequently, an elaborated passkeys and device management is required to administer the passkeys for the user.

CDA-first login processes involve using the smartphone-stored passkeys, thus also the smartphones local platform authenticator needs to be used.

The regular WebAuthn authentication flow is executed.

In general, the user needs to provide the login identifier (e.g. email address, phone number, username) that they used for creating the account. This provision of the login identifier can also work via Conditional UI. This would then be usernameless and work slightly different (see below).

Now, there can be different scenarios on desktops depending on the existence of a local passkey on the desktop. We provide an overview of the scenarios below. Here, passkey-ready means the desktop supports local platform authentication. Conditional-UI-ready means the desktop supports Conditional UI.

In all cases, we assume WebAuthn-readiness and availability of Bluetooth.

• Desktop is passkey-ready and has a passkey: A typical use case would that you're on a MacBook where synced passkeys, e.g. from an iPhone are available via the same iCloud Keychain or a modern Windows 11 laptop where the user has created a single-device passkey before.

  • Desktop is Conditional-UI-ready: In this scenario, the Conditional UI popup automatically appears (unless there's specific logic to block it on desktop devices). Thus, the relying party has limited control over which passkey the user opts to use. Users have the freedom to choose any displayed local passkey. They can also opt for a connected smartphone to facilitate cross-device authentication. However, the system does not allow for directly blocking the use of a local passkey.
  • Desktop is not Conditional-UI-ready: In this case, the relying party, through the WebAuthn server and PublicKeyCredentialRequestOptions, can influence passkey behavior. If the allowCredentials property is limited to hybrid passkeys that were generated and stored on a different device, the operating system will automatically present the QR code for CDA (refer to this blog post for more details on the behavior).

• Desktop is passkey-ready and has no passkeys: In this scenario, the user has not yet created a passkey on the desktop but has done so on their smartphone.

  • Desktop is Conditional-UI-ready: The Conditional UI popup should display only the option to use a passkey from a smartphone, without showing any locally stored passkeys. This option appears only if a synced passkey from a smartphone is available (e.g., from iCloud Keychain or a third-party password manager with passkey creation capabilities).
  • Desktop is not Conditional-UI-ready: The behavior is identical to when the desktop is not Conditional-UI-ready.

• Desktop is not passkey-ready and has no passkey: In this scenario, the CDA flow is triggered immediately, displaying the QR code. The user then scans this QR code with their smartphone to authenticate. There will be no option to create a passkey on the desktop after successful login since the system recognizes the desktop device as not passkey-ready.

• Desktop is not passkey-ready and has a passkey: This scenario is not possible.

If the desktop is passkey-ready (possesses a platform authenticator), automatically generating a new local passkey after CDA (Post-CDA passkey creation) can be enforced to further streamline the login process for future access.

Below, the schematic flows for the login process are detailed for both Conditional-UI-ready and non-Conditional-UI-ready desktop devices. Step number 3 may be automated in some browsers (e.g., Chrome), saving the device so that only a Bluetooth proximity check is needed, without the necessity for QR code scanning.

In a previous, more detailed article, we analyzed how user login experiences can be customized based on the transports settings. These findings remain valid and applicable, contingent upon the specific configurations used.

Moreover, since the publishment of the prior blog post, Android has upgraded to also serve as CDA client and is now able to display QR codes, so we extend our analysis to Android. Therefore, we used an Android 14 smartphone together with Chrome 123, Edge 123 as well as Firefox 119 for our test case. Please see the results below:

Recovery scenarios are simplified, as the primary authentication method resides on the user's smartphone, reducing the dependency on traditional recovery methods. This means that breaking your desktop or loosing access to it is not that much of a problem but the more fragile component becomes the smartphone. However, in the cases of smartphones and as most modern smartphones sync their passkeys, it's highly unlikely to completely loose access to your passkeys. To learn more why it's that complex to lose access to an iCloud or Google account (and the respective passkeys), please see the following two engineering blog posts:

• Apple: About the security of passkeys
• Google: Security of passkeys in the Google Password Manager

This section outlines the technical considerations and necessary settings to implement the CDA-first system. The focus is on the modification of PublicKeyCredentialCreationOptions and PublicKeyCredentialRequestOptions (mainly the use of the transport property of credentials and the authenticatorAttachment property) as well as more sophisticated passkey and device management in the backend. For more details regarding the behavior of the transports property on different operating systems and browsers, see this blog post.

There's a new WebAuthn extension called credential hints that can be specified during credential registration. This setting in the WebAuthn server properties allows the specification of the type of credential to be created. There are three values possible to be set in the array (none, one or multiple; with priority in descending order). They are officially introduced in the WebAuthn Level 3 draft specification and as of April 2024 they are not yet supported by any major browser (so developers still have to rely on the existing authenticatorAttachment).

• client-device: Signals the relying party's intention for browsers to facilitate user registration via platform authenticators, analogous to specifying authenticatorAttachment: "platform".
• security-key: Directs the browser to guide user registration through a hardware security key (e.g. YubiKey). It's similar to authenticatorAttachment: "cross-platform".
• hybrid: Enables relying parties to advocate for passkey registration via cross-device authentication. Currently, this method comes together with the hardware security keys option when authenticatorAttachment: "cross-platform" is set.

The reason for the credential hints to exists is that providing cross-platform vs. platform authenticators is not sufficient anymore in the modern world of passkeys. Both existing options stemmed from a time, when there were no cross-device synced credentials. With the credential hints, you can tune the cross-platform registration flow to trigger hybrid registration specifically (so users will not be confused with cross-platform authenticators like YubiKeys).

Once WebAuthn Level 3 becomes ubiquitously available, credential hints are supposed to overrule any value of authenticatorAttachment (it's even planned that in WebAuthn Level 4 authenticatorAttachment gets deprecated). This option allows clients to tailor the user experience accordingly. For more details on this topic, I recommend to have a look at this blog post.

For the PublicKeyCredentialCreationOptions, setting authenticatorAttachment to "cross-platform" is necessary (or at least including it besides "platform"). This configuration enables the use of cross-platform authenticators (formerly called roaming authenticators), which are authenticators that can be moved around and used across multiple devices.

By defaulting to cross-platform authenticators, services can cater to users who utilize smartphones as their primary authentication method.

{
  "rp": {
    "origins": [
      "https://passkeys.eu"
    ],
    "name": "Passkeys Demo"
  },
  "challenge": "AAABeB2sHrIemh1jTdJICr_3QG_RMOhp",
  "pubKeyCredParams": [
    {
      "type": "public-key",
      "alg": -257
    },
    {
      "type": "public-key",
      "alg": -35
    },
    {
      "type": "public-key",
      "alg": -36
    },
    {
      "type": "public-key",
      "alg": -7
    },
    {
      "type": "public-key",
      "alg": -8
    }
  ],
  "excludeCredentials": [],
  "timeout": 120000,
  "authenticatorSelection": {
    "residentKey": "required",
    "requireResidentKey": true,
    "userVerification": "preferred",
    "authenticatorAttachment": "cross-platform"
  },
  "attestation": "direct",
  "user": {
    "name": "Vincent",
    "displayName": "Vincent Delitz",
    "id": "bWY2aXd3"
  }
}
 

To use cross-platform authentication properly, the transports value of a credential should include the value "hybrid". Most of the times, the value "internal" is set as well. The values are set in the PublicKeyCredentialRequestOptions.allowCredentials list. This can be double checked by a backend that has advanced passkey and device management capabilities to ensure that really only passkeys that were created on a smartphone are set in the allowCredentials list. If you also allow to use passkeys that might have been added later after successful mobile-first CDA login, then other credentials (without the "hybrid" value in transports) can also be added to the allowCredentials list.

{
  "challenge": "EGYtAMgi8B2Ey1FNVfVF93m5LEz_CfwTy00W2zoPEN4",
  "timeout": 120000,
  "allowCredentials": [
    {
      "type": "public-key",
      "id": "4lUEEpMVrnEL1t3P9a9r6Y5e4lGF9SM-kx4EQjqLxZ0",
      "transports": [
        "hybrid",
        "internal"
      ]
    }
  ],
  "hints": [
    ""
  ],
  "userVerification": "required"
}
 

For the successful deployment of a CDA-first authentication strategy, a robust backend to manage passkeys and device associations is necessary. This ensures that the correct authentication flows are applied on authorized devices (mainly through providing the right credentials in the allowCredentials list). Diving into the specifics of backend adaptation is beyond the scope of this blog post.

Let's analyze if the proposed system has fulfilled the requirements we defined in section 3.

• ✅ RQ1 Smartphone as Central Passkey-Holding Device: This requirement is fulfilled as the smartphone is primarily used when creating an account / passkeys as well as when a login is triggered. The only case where the behavior can deviate is if the desktop device is Conditional-UI-ready and a passkeys is locally available. Then the user would have the chance to directly log in with the passkey from the desktop
• ✅ RQ2 Desktop Passkey Creation is Optional: This requirement is fulfilled, as users can still skip the steps where they can create a local passkey on a desktop.
• ✅ /❌ RQ3 CDA Flows before Local Authentication Flows: This requirement is partially fulfilled, as in principle, CDA flows are preferred and used as the primary login method. However, depending on the Conditional-UI-readiness of a desktop, also the local authentication flow can be used immediately.
• ✅ /❌ RQ4 Use WebAuthn Standard QR Codes Instead of Custom Solutions: This requirement is partially fulfilled. We haven't modified the CDA flow and thus the standard WebAuthn cross-device authentication flow is used. However, in scenarios, where any of the two involved devices (client or authenticator) has no Bluetooth capabilities, one need to introduce a proprietary QR code solution that does not rely on Bluetooth for proximity checks (but maybe implement something else to keep security levels high).

In summary, the requirements have been fulfilled. Besides all the above mentioned aspects, there are some things we have (on purpose) not yet discussed but would need to get some consideration in a real-life application, namely:

• Hardware Security Keys: How to deal with hardware security keys (e.g. YubiKeys), especially how can we avoid user confusion if the credential hints are not yet available?
• Third-Party Password Managers: How to properly deal with third-party password managers, as they can sync passkeys across devices and across platforms?
• Integration Into Existing Systems: How to avoid friction and ensure a smooth user experience, when CDA-first pattern is introduced to a system that has an existing authentication solution in place?

The journey toward a universally accessible passkey ecosystem, especially with different devices and platforms, necessitates innovative authentication strategies. The CDA-first approach, prioritizing mobile-first CDA passkey authentication, emerges as a compelling solution to solve the challenges posed by the current disparity in passkey readiness among devices (especially on Windows, ChromeOS and Linux devices). By leveraging the ubiquity of smartphones, alongside familiar technologies like QR codes and Bluetooth, this approach addresses synchronization and recovery issues.

Despite some limitations, such as smartphone dependency and potential redundancy on passkey-ready desktops, the CDA-first pattern offers universally accessible, secure, and user-friendly authentication. Its implementation requires sophisticated passkey and device management in the backend and a good understanding of WebAuthn server settings. Done properly, it can be the desired authentication strategy for certain use cases.