WebAuthn Autocomplete for Passkey & Password Autofill

1. Introduction

2. What is the Autocomplete Attribute?

3. What's the Support for WebAuthn Autocomplete?

4. WebAuthn AutoComplete Implementation Guide

    4.1 Prerequisites for WebAuthn AutoComplete

    4.2 Enabling AutoComplete in the User Interface

    4.3 Initiate the WebAuthn Authentication Ceremony

    4.4 AbortControllers in WebAuthn

5. Analysis of Different Browser & Operating System Behaviors

    5.1 Definition WebAuthn AutoComplete Use Cases

    5.2 Findings WebAuthn Autocomplete Use Cases

      5.2.1 iOS 17.4.1 (on Chrome: 16.7.5)

      5.2.2 Android 14

      5.2.3 macOS 14.4.1

      5.2.4 Windows 10 (22H2)

      5.2.5 Windows 11 (23H2)

    5.3 Definition WebAuthn AutoComplete Edge Cases

    5.4 Findings WebAuthn AutoComplete Edge Cases

      5.4.1 iOS 17.4.1 (on Chrome: 16.7.5)

      5.4.2 Android 14

      5.4.3 macOS 14.4.1

      5.4.4 Windows 10 (22H2)

      5.4.5 Windows 11 (23H2)

6. Recommendation for Developers

    6.1 Scenario A: The user-friendly but conservative way

    6.2 Scenario B: The progressive passkey-pushing way

      6.2.1 Passkey and Password Autofill on Android and Chrome with Google Password Manager

      6.2.2 Passkey and Password Autofill on Windows 11 with Google Password Manager

      6.2.3 Passkey and Password Autofill on iOS with iCloud Keychain

      6.2.4 Passkey and Password Autofill on macOS with iCloud Keychain

    6.3 Scenario C: The passwordless way

7. Conclusion

The widespread technical availability of passkeys, and in particular Conditional UI, is a real game-changer in user authentication. To make Conditional UI work, the webauthn autocomplete token is required in the HTML. This HTML attribute can be used in conjunction with other existing autocomplete attributes such as username, email and current-password. Its goal is to facilitate a user-friendly transition from passwords to more secure and convenient passkeys.

However, the behavior of the webauthn autocomplete token varies across different browsers and operating systems. This is due to the different behavior of Conditional UI based on the browser and operating systems. Sometimes you get the “passkey autofill” (synonym for Conditional UI) immediately upon page load, sometimes it requires user interaction with e.g. an input field. The lack of comprehensive documentation about this behavior and about edge cases (What if there are two input fields with both the autocomplete webauthn token?) present adds a layer of uncertainty. With this blog post, we aim to take a look at scenarios like:

• How does the webauthn autocomplete behave when there is a password field already?
• How does the webauthn autocomplete behave when there is an OTP field already?
• What if there are multiple autocomplete webauthn fields (e.g. email address + username)?

Addressing these uncertainties, we take a deeper look into the mechanics of the webauthn autocomplete attribute, the connection to Conditional UI, and how different scenarios map out in real-world applications.

Therefore, we set up a simple JavaScript-based WebAuthn server to test various scenarios, ranging from single to multiple autocomplete fields, across diverse browsers and operating systems. With the findings, we aim to bring some light on the behavior of this attribute in different contexts and provide developer recommendations to improve the UX.

In web development, the HTML autocomplete attribute enhances the user experience by providing automated assistance in filling out form fields. This attribute communicates directly with the user agent – commonly a web browser – guiding it on how to handle the prefilling of form controls. Let’s take a closer look at it:

• General Functionality: The autocomplete attribute can be set to off or on, or it can take a series of space-separated tokens that provide specific instructions on how the user agent should prefill the input.

• HTML Element Scope: It’s applicable to <input>, <textarea>, <select> and <form> elements.

  • <input> accepts text or numeric values
  • <textarea> accepts larger text inputs
  • <select> allows the pre-selection from a drop-down list
  • <form> encapsulates a collection of inputs

• Behavior: When an element such as <input>, <select>, or <textarea> lacks a dedicated autocomplete attribute, the browser defaults to the setting of the element's owning form. This owning form is defined by the ID specified by the form attribute of the element or the form element within which it resides.

• Usage Guidance: For a comprehensive understanding of the various tokens that can be used with the autocomplete attribute, developers are encouraged to refer to the documentation on the Mozilla Developer Network (MDN) Web Docs.

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

Subscribe

The adoption of the autocomplete="webauthn" value across the web is still gaining momentum. Here's an insight into the current landscape of support for this attribute. Major browsers such as Chrome, Edge, Safari and Firefox have embraced Conditional UI, which incorporates support for the autocomplete="webauthn” value.

To get the most current data on the support for autocomplete="webauthn" and other features, developers should consult direct resources such as browser documentation, feature announcements, and real-time testing tools. The Can I Use website remains a valuable starting point for compatibility checking but should be complemented with additional resources for the most accurate information. In the case for “Can I use autocomplete: webauthn?”, the website displays a lack of support for Safari and Firefox and overall only 73.24% support. However, this data cannot hold true, as we have successfully tested on Safari and Firefox (see below).

Also checking the browser compatibility on the Mozilla Developer Network (MDN) Web Docs doesn’t really reflect the reality, as Firefox and Safari are deemed to not support the webauthn token as well.

Integrating autocomplete=”webauthn” into your application requires adherence to certain prerequisites and an understanding of the necessary steps to handle the WebAuthn authentication ceremony.

Become part of our Passkeys Community for updates and support.

Join

Technically, there are some prerequisites for autocomplete=”webauthn” or Conditional UI in general to work:

• Browser and OS Support: Ensure that the operating system is passkey-ready and that the user's browser supports autofill functionality. Besides the operating system being passkey-ready, its authenticator also needs to allow the detection and listing of passkeys (e.g. on Windows 10, you can create device-bound passkeys but the listing of passkeys in an autofill menu is not possible).

• Feature Detection: Check for the support of Conditional UI programmatically, as outlined in our guidance for Autofill / Conditional UI browser feature detection for passkeys.

• Implementation of WebAuthn Server: Implement a WebAuthn server to generate PublicKeyCredentialRequestOptions, which are sent back to the authenticator for the authentication ceremony.

Let’s start by implementing the AutoComplete feature in the UI / frontend:

1. Create Form: We start out by adding a simple form to our HTML page.

2. Add Attribute to Input Tag: Introduce an <input> tag with autocomplete="username webauthn" to facilitate the autofill feature for WebAuthn. In this case, we start by adding the “webauthn” token to the username input field ( more variations later). In general, in can be combined with traditional autofill tokens (e.g. “email webauthn” or “current-password webauthn”). Check our GitHub for the full webauthn-autocomplete example code.

<input type="text" id="username-field" autocomplete="username webauthn" />

Next, we need to trigger a WebAuthn authentication ceremony configured for Conditional UI (Conditional Mediation), which differs slightly from the regular WebAuthn authentication request. Please see the following code snippet for reference:

// Example method to handle WebAuthn authentication using conditional mediation
async function conditionalMediationLogin() {
 
    handleAbort();
    abortController = new AbortController();
 
    // Adjusted publicKeyCredentialRequestOptions for conditional UI
    const publicKeyCredentialRequestOptions = {
        challenge: generateChallenge("randomChallengeString"),
        timeout: 60000,
        userVerification: "preferred",
        rpId: "webauthn-autocomplete.vercel.app"
    };
 
    try {
        const assertion = await navigator.credentials.get({
            publicKey: publicKeyCredentialRequestOptions,
            mediation: "conditional",
            signal: abortController.signal
        });
        console.log("Conditional login successful", assertion);
        updateStatus(`Conditional login successful`);
    } catch (err) {
        console.error("Conditional login error", err);
        updateStatus(`Conditional login failed: ${err.name} `);
        if (err.name === 'AbortError') {
            updateStatus('Conditional login aborted.');
        }
    }
} 

Let’s briefly analyze what happens in the code:

• Communicating with Relying Party: We utilize the conditionalMediationLogin() method to communicate with the Relying Party to get the PublicKeyCredentialRequestOptions including the challenge. Usually this would happen on the server-side but in our example, we mimic the WebAuthn server behavior in the frontend and just provide the PublicKeyCredentialRequestOptions in the frontend.

• Mediation Property: When configuring the PublicKeyCredentialRequestOptions, include a mediation property with the value "conditional" to trigger the Conditional UI WebAuthn flow.

• Get the Credentials Locally: The PublicKeyCredentialRequestOptions are then put into the navigator.credentials.get() function which triggers the local authentication (e.g. Face ID, Touch ID, Windows Hello).

• Assertion Handling: Upon successful credential retrieval, the assertion (incl. the signed challenge) would be sent back to the server which verifies the assertion and then creates the session. In our local example, we just display the result of the authentication ceremony by updating the status field in the frontend.

Note, that removing the mediation property reverts the process to a regular WebAuthn authentication ceremony.

In the context of WebAuthn- / passkey-based applications, the AbortController can be used to abort the registration or authentication processes if the calls are taking too long or if certain conditions change (e.g., user navigates away, closes a modal, or decides to cancel the operation). WebAuthn operations can sometimes be lengthy due to user interaction requirements (like user verification or device selection), and having a way to cancel these operations can improve the user experience and system performance.

When calling WebAuthn APIs (navigator.credentials.createfor registration or navigator.credentials.get for authentication), include the signal property in the options and assign the AbortController.signal to it (see the code samples).

To abort the operation (e.g. the user presses a “cancel” button), abortController.abort() needs to be called.

function handleAbort() {
    if (abortController) {
        abortController.abort();
        abortController = null;
    }
}

This triggers any ongoing WebAuthn operation that is listening to the same signal to stop and throw an AbortError.

The most important coding parts for testing and playing around with the webauthn autocomplete token have now been described. In real-life applications (and in our example application), we also included the functionality to create a new passkey and also to do a regular WebAuthn authentication. Please take a look at our GitHub repository for the full code.

After, we have built the application, we deployed it to Vercel and made it publicly available at https://webauthn-autocomplete.vercel.app, so that it can be accessed from different operating systems browsers to analyze the behavior of the webauthn autocomplete functionality.

Specifically, we tried to

• Outline the current support level for webauthn autocomplete across various browsers and operating systems and test edge cases.

• Explain the UX differences, like immediate popups or input field clicks, in various environments.

Moreover, we knew that the following two assumptions should hold true:

1. The autocomplete attribute has a grammar with a strict order that parses right-to-left. Thus, the webauthn autocomplete token should fit naturally at the end of the tokens.
2. webauthn autocomplete token is only valid for <input>and <textarea> elements.

To validate these assumptions, we also included a dedicated use and edge case.

To check properly how things behave based on different examples for the webauthn autcomplete token, we came up with ten use cases that we tested on different operating systems and browsers:

1. WebAuthn only: only use the webauthn autocomplete token. Not even a username needs to be provided, as this will be randomly set for this case

<input id="loginInput" autocomplete="webauthn">

2. Username only: use the webauthn and usernameautocomplete token. Also during sign-up, the only things that needs to be provided is the username.

<input type="text" id="loginUsername" autocomplete="username webauthn">

3. Email only: use the webauthn and email autocomplete token. During sign-up, the only things that needs to be provided is the email.

<input type="email" id="loginEmail" autocomplete="email webauthn">

4. Phone number only: use the webauthn and tel autocomplete token. During sign-up, the only things that needs to be provided is the phone number.

<input type="tel" id="loginPhonenumber" autocomplete="tel webauthn">

5. Username + Password: use the webauthn and current-password autocomplete token. During sign-up, the only things that needs to be provided is the username.

<input type="text" id="loginUsername" autocomplete="username webauthn">
<input type="password" id="loginPassword" autocomplete="current-password webauthn">

6. Email + Password: use the webauthn and current-password autocomplete token. During sign-up, the only things that needs to be provided is the email.

<input type="email" id="loginEmail" autocomplete="email webauthn">
<input type="password" id="loginPassword" autocomplete="current-password webauthn">

7. Phone number + OTP: use the webauthn and one-time-code autocomplete token. During sign-up, the only things that needs to be provided is the email.

<input type="tel" id="loginPhonenumber" autocomplete="tel webauthn">  
<input type="text" id="loginOtp" autocomplete="one-time-code webauthn">

8. Username + Email + Password: use the webauthn and current-password autocomplete token. During sign-up, the only things that needs to be provided is the email or username.

<input type="email" id="loginEmail" autocomplete="email webauthn">
<input type="text" id="loginUsername" autocomplete="username webauthn">
<input type="password" id="loginPassword" autocomplete="current-password webauthn">

9. Username + Email + OTP: use the webauthn and one-time-code autocomplete token. During sign-up, the only things that needs to be provided is the email or username.

<input type="email" id="loginEmail" autocomplete="email webauthn">
<input type="text" id="loginUsername" autocomplete="username webauthn">
<input type="text" id="loginOtp" autocomplete="one-time-code webauthn">

10. Textarea: use the webauthn and on autocomplete token. Not even a username needs to be provided, as this will be randomly set for this case.

<textarea id="loginEmail" name="user-info" rows="4" cols="50" autocomplete="on webauthn"></textarea>

In general, we made the following observations across the operating systems and browsers.

• Across operating systems and browsers, the evaluation of the webauthn autocomplete token is very heterogeneous. Some use cases were supported while others were (see the details in the table below).

• Conditional UI was not available on

  • iOS 17.4.1 and Chrome
  • iOS 17.4.1 and Firefox

• Android required a different configuration of the WebAuthn server settings. TODO

• Windows 10 (22H2) and Edge does not offer the “Use a passkey” dropdown

• Applying the webauthn token to a <textarea> element did not have an effect for any operating system or browser.

We tested the following combinations of browsers and operating systems and checked how they behave for each use case. In case we observed any anomaly, we added our finding to the table below.

For our testing, we used an iOS 17.4.1 for Safari but for testing Chrome we purposely used an iPhone with older operating system version (here 16.7.5). On iOS 17.4.1 using Chrome, Conditional UI is not working due to a bug introduced by Apple in the operating system software.

For Edge, we did no testing, and for Firefox there was no Conditional UI available by the time of writing the blog post.

For Chrome 124 and Edge 124, we made an interesting observation. In use case #2, the Conditional UI bottom up emerged when the user clicked into the sign-up username input element, even though the webauthn token was not set for this input field.

Conditional UI on Firefox 125 for Android is not available as of May 2024.

Due to the rare use case, we did not test Edge for macOS.

Windows 10 does not support Conditional UI (passkey autofill), so we tested for the autocomplete option “Use a passkey” option that facilitates the Cross-Device Authentication (CDA) flow.

See these screenshots as reference (first Chrome, then Firefox):

Chrome "Use a passkey"

Firefox "Use a passkey"

Besides the regular use cases, we also tested four edge cases where we knew in advance that things might not work as expected but still wanted to show you the behavior in different browsers.

1. 2 login forms (2x username) in one page: There are two login forms for username & password logins in one page.

<form id="loginForm1">
    <h2>Login</h2>
    <label for="loginUsername1">Username:</label><br>
    <input type="text" id="loginUsername1" autocomplete="username webauthn"><br>
    <label for="loginPassword1">Password:</label><br>
    <input type="password" id="loginPassword1" autocomplete="current-password webauthn"><br>
    <button type="button" id="login1">Login</button>
</form>
<form id="loginForm2">
    <h2>Login</h2>
    <label for="loginUsername2">Username:</label><br>
    <input type="text" id="loginUsername2" autocomplete="username webauthn"><br>
    <label for="loginPassword2">Password:</label><br>
    <input type="password" id="loginPassword2" autocomplete="current-password webauthn"><br>
    <button type="button" id="login2">Login</button>
</form>

2. 2 login forms (2x email) in one page: There are two login forms for email & password logins in one page.

<form id="loginForm1">
    <h2>Login</h2>
    <label for="loginEmail1">Email:</label><br>
    <input type="email" id="loginEmail1" autocomplete="email webauthn"><br>
    <label for="loginPassword1">Password:</label><br>
    <input type="password" id="loginPassword1" autocomplete="current-password webauthn"><br>
    <button type="button" id="login1">Login</button>
</form>
<form id="loginForm2">
    <h2>Login</h2>
    <label for="loginEmail2">Email:</label><br>
    <input type="email" id="loginEmail2" autocomplete="email webauthn"><br>
    <label for="loginPassword2">Password:</label><br>
    <input type="password" id="loginPassword2" autocomplete="current-password webauthn"><br>
    <button type="button" id="login2">Login</button>
</form>

3. 2 login forms (username + email) in one page: There is a separate login form for username & password as well as for email & password in one page.

<form id="loginForm1">
    <h2>Login</h2>
    <label for="loginUsername">Username:</label><br>
    <input type="text" id="loginUsername" autocomplete="username webauthn"><br>
    <label for="loginPassword1">Password:</label><br>
    <input type="password" id="loginPassword1" autocomplete="current-password webauthn"><br>
    <button type="button" id="login1">Login</button>
</form>
<form id="loginForm2">
    <h2>Login</h2>
    <label for="loginEmail">Email:</label><br>
    <input type="email" id="loginEmail" autocomplete="email webauthn"><br>
    <label for="loginPassword2">Password:</label><br>
    <input type="password" id="loginPassword2" autocomplete="current-password webauthn"><br>
    <button type="button" id="login2">Login</button>
</form>

4. WebAuthn token first: The webauthn autocomplete token comes before the email autocomplete token.

<input type="email" id="loginEmail" name="email" autocomplete="webauthn email">

In general, we made the following observations across the operating systems and browsers.

• Only iOS 17.4.1 and macOS supported the edge cases where the webauthn autocomplete token comes before other tokens
• Edge cases 1-3 worked for all operating systems & browsers if they supported the webauthn autocomplete token anyway.
• Safari (on iOS and macOS) is the only browser where all edge cases worked

In the following, you find the tested combinations of browsers and operating systems. In case we observed any anomality, we added our finding to the table below.

Firefox 125 does not support Conditional UI as of May 2024.

To test the edge cases on Chrome 124, we used an iPhone with iOS 16.7.1, as Apple introduced a bug that prevents Conditional form working on Chrome in iOS 17.4.1.

Windows 10 does not support Conditional UI (passkey autofill), so we tested for the autocomplete option “Use a passkey” option that facilitates the Cross-Device Authentication (CDA) flow.

As you’ve seen in the previous sections: implementing Conditional UI and using the webauthn autocomplete token is a useful thing from UX perspective. In the following, we provide recommendations for three very common scenarios:

You already have an email and password field in your application. While you might consider using passkeys, you are not yet ready to offer Conditional UI for whatever reason. Therefore, you implement passkeys / WebAuthn only in the modal way (no passkey autofill). Still, you offer autofill for the user’s email and password field. Both input fields provide to fill the email address and password when clicked on them.

In this case, we provide the following code recommendation for autofill:

<input type="email" id="loginEmail" autocomplete="email">
<input type="password" id="loginPassword" autocomplete="current-password">

You already have an email and password field in your application. Moreover, you added passkey / WebAuthn functionality and want to promote it by offering Conditional UI (passkey autofill). You want to trigger the passkey autofill independently if the user clicks on the username or password field.

How this scenario maps out on different operating systems and browsers depends on the different autofill capabilities and the passkey provider / password manager where the credentials are stored. We tested this scenario on some popular devices and password managers to give a better overview of the UX which will be pretty common for applications that authenticate users today with passwords and start to gradually transition them to passkeys (via Conditional UI).

Both credentials (passkey and password) are shown in the bottom up component and the user just needs to click on the passkey (first credential) to start the passkey login or password (second credential) to prefill the email address and password.

The following screenshot was made with Chrome.

On Windows 11, the user can click either into the email or password field and the autofill menu will be the same. Both credentials (passkey and password) are presented in the same menu and a click on passkey triggers the passkey login while a click on the password pre-fills the email address and password.

The following screenshot was made with Chrome.

On iOS and Chrome, once the user clicks either into the email address or password field the “sign in with passkey for <rpID>” text appears on top of the keyboard. By clicking on it, the passkey login flow starts.

If the user wants to autofill the email address and password, they need to click on the key icon besides the passkey text and can select their password credential. Thus, it’s obvious that iOS prioritizes passkeys over passwords.

The following screenshot was made with Chrome.

The following two screenshots are made on Safari, where the initial behavior when opening a Conditional UI website differs to the behavior on Chrome. Here, independently if the user clicked on an input element the keyboard opens a large button to start with the passkey authentication becomes visible. By clicking on it the passkey login starts.

If the user clicked somewhere else, e.g. in the password field or clicks later again in the email field, the second screenshot appears where the behavior is the same to Chrome – with a slight difference in the text being displayed (no rpID) on top of the keyboard.

On macOS and Chrome, once the user clicks either into the email address or password field, the autofill dropdown appears. Here the user sees all the passkeys and passwords in the same autofill and menu and can select any to either start the passkey login ceremony or autofill the email address and password.

The following screenshot was made with Chrome.

On macOS and Safari, the autofill menu appears immediately when the user opens the website. The autofill menu also stays when the user clicks in the password field. To get access to the passwords, the user would need to click on the option “iCloud Keychain…” where they can select the email address and password for autofilling.

The following screenshot was made with Safari.

In this case, and thus for all the four described devices and passkey providers, we provide the following code recommendation for autofill:

<input type="email" id="loginEmail" autocomplete="email webauthn">
<input type="password" id="loginPassword" autocomplete="current-password webauthn">

You want to remove the password field from your first screen by only offering a field to enter the email address (a password field might appear on a second page after but does not need to). With Conditional UI, available passkeys will show up in the autofill menu and can trigger the WebAuthn login ceremony. If the user does not use Conditional UI but has a passkey, then the WebAuthn login ceremony will also start. Only if the user does not have a passkey, then the next page which will ask for a password will show up (here password autofill can be leveraged again). This approach is also presented by Apple in their initial passkey reveal at WWDC22. It can also be branded as “email first” sign-in flow.

In this case, we provide the following code recommendation for autofill:

<input type="email" id="loginEmail" autocomplete="email webauthn">

Moreover, besides these recommendations for the three scenarios, keep in mind that the particular behavior differs among the different operating systems and browser versions. That’s why we also recommend to:

• Employ Conditional UI / webauthn token as often as possible: to reach higher passkey adoption rates and provide the best UX, you should go for Conditional UI and thus the webauthn token as often as possible.
• Monitor operating systems & browser updates: Play close attention to new updates from operating systems & browsers, as they might affect the autofill menus or enable new ways to facilitate the login experience for users on some devices.

The integration of the webauthn autocomplete and the use of Conditional UI deliver the best login experience for users. By reducing cognitive load and enhancing security, the webauthn autocomplete token improves overall user satisfaction and boosts confidence in security measures. For developers, managing the differing behaviors of autofill across various HTML elements can present a challenge. It is crucial to continuously monitor updates to provide the best user experience on all devices and operating systems. Additionally, the transition from passwords to passkeys can be significantly streamlined with autofill features and thus can be a nice lever to make the Internet a safer place.