{"id":15687,"date":"2025-12-17T12:31:02","date_gmt":"2025-12-17T06:31:02","guid":{"rendered":"https:\/\/dtasiagroup.com\/?p=15687"},"modified":"2025-12-17T12:31:02","modified_gmt":"2025-12-17T06:31:02","slug":"ux-best-practices-for-passkeys-understanding-device-initiated-authentication","status":"publish","type":"post","link":"https:\/\/dtasiagroup.com\/vi\/ux-best-practices-for-passkeys-understanding-device-initiated-authentication\/","title":{"rendered":"UX Best Practices for Passkeys: Understanding Device-Initiated Authentication"},"content":{"rendered":"
\n
\"Device-Initiated<\/div>\n<\/div>\n
\n
\n
\n

 <\/p>\n

\n
\n
\n
\n

Passkeys are different from traditional username-based approaches to passwordless sign-in and MFA. This article explains how to design the most effective passkey experience for users, with a focus on web browsers as the platform.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

‍<\/p>\n

Username-initiated authentication<\/h3>\n
\n
\n
\n
\n
\n
\n
\n
\n

On web browsers, traditional passwordless sign-in usually starts with the user providing some form of identifier. For instance, the user might be asked to enter their email address to trigger a challenge through an email OTP code or a magic link.‍<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/article>\n<\/div>\n

\n
\"\"<\/div>\n<\/figure>\n

The email address here acts as a username which is necessary both to look up the account and to verify that it belongs to the user. We need to find the account associated with the email address and then send out an email that can be used to verify account ownership.<\/p>\n

‍<\/p>\n

Device-initiated authentication<\/h3>\n

A key difference between passkeys and traditional passwordless sign-in is that authentication doesn\u2019t need to start with the user entering a username, such as an email address.<\/p>\n

This is because passkeys are tied to devices\u2014either restricted to a single device (\u201cdevice-bound\u201d) or synced across multiple devices via a backend service (e.g., iCloud Keychain or Google Password Manager). As a result, we can show the passkeys available on the device without first asking the user for their username. When the user selects a passkey, an internal identifier on the credential is used to locate their account.<\/p>\n

Typically, a user will have at most one passkey per website. However, if a device is shared among family members or if a user has multiple accounts on the same site, multiple passkeys may be presented for selection.<\/p>\n

\n
\"\"<\/div>\n<\/figure>\n

‍<\/p>\n

Passkey autofill<\/h3>\n
\n
\n
\n
\n
\n
\n
\n
\n

Passkey autofill is an example of device-initiated authentication. While it does require a username input field, the user only needs to focus on this field to view and select any available passkeys. They don\u2019t have to finish typing their username to access and choose a passkey.<\/p>\n

\"\"<\/p>\n

Because it only shows passkeys if they\u2019re available on the device, the autofill feature is an unobtrusive way to introduce passkeys to your sign-in page. If the user hasn\u2019t set up a passkey yet and doesn\u2019t know what they are, then they can still enter their username and proceed through a more familiar passwordless authentication challenge such as email OTP. But for users who do select an autofilled passkey, the site can look up their account based on the passkey selected. In addition, the site can authenticate the user at the same time by looking up the public key associated with the account and using it to verify the signature generated by the passkey\u2019s private key.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/article>\n<\/div>\n<\/div>\n<\/div>\n

<\/div>\n
\n
\n

<\/h3>\n

A passkey sign-in button<\/h3>\n

Another way of supporting passkey sign-in, which can be used alongside autofill, is to add a separate button that is clearly labeled as a passkey sign-in option.<\/p>\n

‍<\/span>‍<\/p>\n

In the above example, a passkey sign-in button is presented as an alternative to the traditional option of entering a username. Like autofill, this button is an example of device-initiated authentication. If the user presses the button, the browser can prompt the user to authenticate with a passkey available on the device.‍<\/p>\n

\n
\"\"<\/div>\n<\/figure>\n

In contrast to autofill, however, the scenario where a device doesn’t have any passkeys available is handled differently. The button is forcing the browser to initiate passkey authentication without knowing whether or not the device has any available; if none are available, then the browser has to fall back on displaying a QR code or wait for the user to insert a security key.<\/p>\n

‍<\/p>\n

\n
\"\"<\/div>\n<\/figure>\n

This may be a valid scenario if the user has previously created a passkey for the site on a different device, and it can’t be synced to their current device. For example, if they originally created the passkey on an iPhone and are now trying to sign-in on a Windows desktop browser, then they can scan the QR code with their iPhone.<\/p>\n

However, the QR code can also be a jarring experience for users who haven’t previously created a passkey or who aren\u2019t familiar with the nuances of how passkeys get synced across different devices. For this reason, it’s important to trigger the QR code flow from a user-interaction, like a passkey sign-in button, where the user has explicitly opted to use passkeys. We want to avoid launching the QR code flow from a context where the user may not anticipate or understand it.<\/p>\n

‍<\/p>\n

Username-initiated passkey sign-in<\/h3>\n

In certain situations, it makes sense to restrict the browser to presenting passkeys for a single user. For instance, when passkeys are used as a secondary factor for MFA, you only want to display passkeys belonging to the user who completed the first authentication step.<\/p>\n

This can be accomplished using the\u202fallowCredentials<\/code>\u202fparameter, which lets you instruct the browser to limit the list of available credentials to those registered for a specific user.<\/p>\n

While MFA is the most typical scenario where\u00a0allowCredentials<\/code>\u00a0would be used, what if you want to use it to design a passwordless sign-in flow? For example, you could prompt the user to manually input their username, look up their account in your system, and then start an authentication challenge by presenting only the passkeys for that user.<\/p>\n

Although\u00a0allowCredentials<\/code>\u00a0does make this possible, there are some limitations to consider. Even if you restrict the browser to a list of credentials for a given user, you can’t know whether those credentials are available on the device that the user is currently authenticating on. For example, the user may be on a device where the passkey they previously created can’t be synced. Alternatively, they may have deleted the passkey from their password manager. For this reason, it’s crucial to always clearly present a backup authentication option, even when using\u00a0allowCredentials<\/code>.<\/p>\n

‍<\/p>\n

Summary<\/h3>\n