Google passkeys: Analysis of sign-ups and logins

TL;DR

• Availability since May 3, 2023
• Initial setup works primarily via https://g.co/passkeys (accessing Google account via the regular URL does not always work)
• Availability of passkeys on all major platforms (iOS, macOS, Windows, Android)
• Passkeys only available at login, not at initial sign-up for an account (yet)
• Passkeys for Android devices are automatically created
• Sophisticated device detection, device management and passkey-readiness detection logic by Google (timestamp, browser and location are saved for passkeys)
• 64% success rate of passkeys, compared to 14% of passwords
• 14.9s login duration of passkeys, compared to 30.4s of passwords, on average

1. Introduction

More and more companies from a wide range of industries are stepping into a password-free world and implement passkeys. Through this series of articles, we aim to provide a comprehensive overview of the passkey user experience of those companies. In each article, we focus on a single company. Today, we dive into Google.

Passkeys became available for Google accounts on May 3, the World Password Day, 2023. The widespread rollout of Google passkeys is a game-changing moment for passkeys, as billions of Google users, along with their devices, have been enabled to use passkeys in one seamless move. This marks a significant milestone for passkeys, from which it is anticipated that many other companies will follow in adopting this technology.

Considering this tipping point, we focus on providing guidance on two important aspects: how Google deals with engaging and transitioning its huge user base to passkeys, and how Google is addressing the challenges still associated with passkeys. This should enable you to incorporate these findings and enhance your product login accordingly.

Disclaimer:

1. Status of the analysis is May 2023. Passkey features are subject to change by companies on an ongoing basis.
2. Please refer to the use cases to find the devices we used for the analysis.

‍

2. Key insights Google analysis

In this section, we present the most important insights we have gained from the analysis of Google passkeys.

2.1 Highlights of Google passkeys implementation

2.1.1 Hybrid rollout strategy

Currently, Google passkeys are only available to log into your Google account. To initially set up a passkey for the device used, the user must go to a dedicated domain: https://g.co/passkeys. This is probably done to start with low risk and find bugs with early adopters (as passkeys flows, especially for cross-device and cross-platform processes, are quite complex to implement). To create a passkey for another device, the user needs to either visit this page or use the "Create passkey" button while logged into the Google account. The user is then redirected to the familiar Google login screen via this page. Users must proactively signal that they want to use passkeys by visiting this page shows that Google is gradually rolling them out to ensure a smooth process for every user.

Even though this approach may be less user-friendly at the moment, it helps to gather feedback from early adopter usage and improve it for all non-technical users who may not be familiar with passkeys as an additional login option. Therefore, all users can still use passwords to log in. This suggests that Google is using a hybrid passkey rollout strategy. This hybrid strategy is characterized by the fact that passkeys can only be used by existing users for login, and that they are not available for sign-up. In addition, legacy login methods are always retained here. This rollout strategy is to ensure a careful transition to passkeys for existing users.

2.1.2 Smart passkey management

Google detects for which devices a passkey has already been created and lists them in the Google account. The detection includes the platform (e.g., Android, Apple, and Windows), the location where the passkey is synced (e.g., Apple iCloud Keychain), the creation timestamp, and the last usage timestamp including browser and location. If the user clicks on these properties, it is possible to view the entire usage history of the passkey over the last 28 days. The listing is divided into passkeys that were created automatically and passkeys that were created manually (see section Conceptual definitions). Although those features don’t prevent the user from clicking the "Create passkey" button for already registered devices (see section Drawbacks) yet, the user is given very clear details about his created passkeys here.

2.1.3 Clear user communication

Google uses the term "passkeys". Since users consciously decide to store passkeys for their account by visiting the website mentioned above, Google probably assumes that these users know what passkeys are (or educate them hereby). As with eBay passkeys (check out our analysis on eBay passkeys for more information), the reference is drawn to the underlying concept of biometric authentication here as well, with which the vast majority of users are likely to be familiar. However, general and no platform-specific authentication methods (e.g., Face ID or Windows Hello) are mentioned here. That said, the term passkeys is only used in the caption of the initial setup and not in the headline of the user message (see use case 1). The headline “Simplify your sign-in” clearly emphasizes the improved UX of passkeys compared to passwords.

‍

2.2.1 Cumbersome cross-device usage

Cross-device usage for passkeys refers to the ability to use a single passkey to authenticate across multiple devices. This means that a user can create a passkey on one device and then use the same passkey to authenticate on other devices, even outside the same ecosystem (e.g. Apple), without having to enroll each device separately. Since this doesn’t work for for passkeys in general in some scenarios not yet, you need to set up a separate passkey on each device outside the same platform ecosystem. For example, if you happen to own an Apple iPhone and an Android phone and want to use Google passkeys on both devices, you will need to create a separate passkey for each of the platforms (within Apple iCloud Keychain and Google Password Manager passkeys are synced across devices though).

2.2.2 No sync within Windows ecosystem

Currently, there’s no solution to sync passkeys across Windows devices. That’s no fault of Google as the technical implementation by Microsoft is still in progress and will probably be released rather soon than later. That means, a new passkey must be created for each Windows device that you want to link to your Google account.

2.2.3 Disabled Conditional UI

Conditional UI leverages the autofill function passkeys provide. It automatically prefills passkeys as soon as the user clicks on the username input field. This means that users no longer need to search for their credentials manually (not even usernames!), as they are already stored in the device / browser and are automatically pre-filled. However, Google has disabled this feature (currently).

2.2.4 Inaccurate passkey detection

Even if a passkey is already stored in the Google account for a device, the “Create passkey” button remains visible, allowing users to manually start the creation process for a new passkey (not for all platforms, but e.g. on Windows). This implies that Google does not clearly detect that a passkey might have already been created for this device. If you try to recreate a passkey, you will be informed that a passkey has already been generated for this device in a proper manner (no bug) and the new one will not be stored.

‍

2.3 Detected edge cases

Manual setup of passkeys in Chrome on macOS (edge case 1)

Even though passkeys might be synced via Apple iCloud Keychain, Chrome on macOS has no access to it and must create a separate passkey.

Some issues with Firefox and Edge on iOS (edge case 2)

When trying to login with a passkey on Firefox and Edge, some strange error messages or white screens appeared that are quite confusing to the user.

Error message on non-passkey-ready devices (edge case 3)

If a device is not passkey-ready, the fallback with passwords is not always handled smoothly and sometimes strange error message appear, when manually starting the passkey creation flow.

WebAuthn virtual authenticator also supported for testing (edge case 4)

Using Chrome DevTools WebAuthn virtual authenticator allows to manually create a passkey and use this virtual authenticator for logins. In the passkey settings at Google, it’s depicted as “Passkey” with no affiliation to the underlying operating system / platform.

Manual deletion of passkey causes error message (edge case 5)

If you manually delete a passkey (not in Google passkey settings, but via the operating system / platform), Google still thinks that the passkey exists and falls into an indefinite loop that you can only escape with an alternative login method.

First login with Windows Hello passkey causes confusion (edge case 6)

If there exists a passkey for another platform and you login with Windows Hello the first time via passkey option, it’s confusing as you’ll be prompted to use a hardware security key. Only after manual passkey creation, Windows Hello uses the platform authenticator (so facial recognition, fingerprint or PIN pattern).

‍

3. Analysis of the login process

To make the analysis of Google passkeys as comprehensive as possible, we tested the login process with several device-browser-combinations. We have recorded the outcomes in the following use cases. To better understand the use cases, please read through the conceptual definitions of passkeys below before jumping into the use cases.

3.1.1 Single-device passkey vs. multi-device passkey

Passkeys come in two distinct types which are single-device and multi-device passkeys. Single-device passkeys are tied to a specific device, meaning that the passkey can only be used on the device it was generated on. Multi-device passkeys are the “true” passkeys that can be synced and transferred between devices. This means that users can use any of their devices that support passkeys to authenticate, regardless of whether the credential was created on that specific device. This greatly enhances the usability of passkeys, as users don’t need to enrol each device.

3.1.2 Automatically created passkeys vs. manually created passkeys

The main difference between automatically created passkeys and manually created passkeys is the way in which they are generated. When using Google passkeys on Android devices, then all Android devices that support passkeys automatically create a passkey when a user logs into their account.  This means that the passkey is generated and stored by the device without the user having to do anything. When logging in with other devices not using Android, however, users must manually create their passkeys.

‍

3.2 Tested cases

The headline does not refer to the term “passkey” but focuses on better user experience in the sign-in process. The description below uses the term “passkeys” but doesn’t refer to any specific biometric authentication concepts like Face ID, Touch ID, or Windows Hello etc.

A success message with the information that the account can now be accessed via biometric authentication (as a synonym for passkeys) is displayed:

When you enter https://g.co/passkeys you are asked to enter your password and, depending on if the device is known, confirm via 2FA. Here, a passkey cannot be created as Google automatically creates passkeys for Android devices that are linked to the Google account (see screenshot below). We expected that for subsequent logins this automatically created passkey will be retrieved. Surprisingly, during our tests, we were only asked for our password but couldn’t use the automatically created passkey. This can be retraced by the timestamp that tracks your personal passkey usage behaviour for every passkey saved for your account. We tried to investigate this by further tests, but we couldn’t find reasons for this so far.

Moreover, on Android, Google also does not support Firefox, Edge or Safari yet (as with Chrome, there was also no way to create a manual passkey on the Android device – we could only use the passkey in Chrome when using it on a MacBook, see below).

Compared to the screenshot above, here Google recognized that we used the automatically created passkey which can be determined by the timestamp. Note that during this login on our MacBook in Chrome, we had to scan a QR Code with our Android (Samsung Galaxy S21 5G), as shown under use case 3.

Even though the MacBook is synchronized with iPhone via Apple iCloud Keychain and should have access to the initial passkey created in use case 1 it is not available for Chrome. This means, that after you’ve logged into your Google account successfully using a different method (or via QR code / Bluetooth passkey), you can create a new single-device passkey to allow subsequent logins in Chrome on the MacBook via passkeys. Specifically, there are two options:

• Option A: Use another device which is linked to the Google account, e.g., Android (here “S21 von Vincent”)
• Option B: Use a different device not linked to the Google account, e.g., iPhone (here “Use a different phone or table”)

Decide for either of the two options:

Option A: After you selected your device, a notification is sent to it:

This is the shown on your MacBook while it’s waiting for the device to confirm:

Option B: Here, we use an iPhone to scan the displayed QR code.

After successful, authentication we can check the created passkeys. The passkey that was used for this login, is the one of the iPhone, so it’s the one from the iCloud Keychain.

From accessing the iCloud Keychain, Safari detects that our user account already has a passkey that is synced in the iCloud Keychain and can make use of it for this login process.

For testing purposes, we clicked on “Sign in with Another Device”. We scanned this QR code with an Android device that is linked to the Google account (but not synced within the Apple ecosystem / iCloud Keychain). Even though we didn’t create a passkey on this Android device before, it was still possible to use it for passkey authentication as Google automatically creates passkeys for devices that are linked to the account (see above).

After successful passkey authentication with the Android device, Safari suggested creating a passkey on our MacBook which would theoretically be synchronized within the Apple iCloud Keychain.

Safari detected the existing passkey within the Apple iCloud Keychain that we created in use case 1 before.

Please note that we didn’t create a passkey for this device before. Besides using Windows Hello or external security key, Google suggested choosing other devices for passkey authentication that are linked to the Google account or that we used in the past. Here we found two noticeable differences.

Firstly, the old devices are not listed under Chrome on macOS (see screenshot above). Secondly, the name of the phone linked to the Google account differs between Chrome under macOS (“S21 von Vincent”) and Chrome under Windows (“SM-G991B”).

For testing purposes, we first selected Windows Hello or external security key (hardware stick). As expected, this didn't work as neither we created a passkey for this device before nor had a security key hardware stick on hand.

After that, we clicked on “Try another way” and used the iPhone from use case 1 on which we created a passkey in Safari. After scanning a QR code (see use case 3 and 4), we were asked to create a passkey. For testing purposes, we declined this. What is noteworthy about this is that we later discovered that on Microsoft you are only asked once to create a passkey. Also, it looked like this request is tied to your account and is independent of the browser you are using. This means that once you have not followed this prompt, it won't reappear when you use another browser. Instead, login is then only possible via already existing passkeys from other devices or manually creating a passkey for Windows in the settings.

When trying to access the Chrome account from another Windows device (here Windows 10), initially, you’re directly prompted to start the passkey authentication process. As this Windows device did not have stored passkey, the following popup appeared and asked to insert a security key in the USB port (which can be quite confusing for non-technical people), so we clicked on “Cancel” and logged in with a passkey from a different device (using QR code and Bluetooth).

After successful login with another passkey, we manually created a new passkey for this Windows machine and saw the following prompt. As this was quite an old Windows laptop without biometric capabilities, we entered the Windows Hello PIN:

Afterwards, a new passkey “Windows Hello 2” showed up in the passkey management settings in the Google account.

Subsequent logins on this Windows machine then directly opened the following prompt, where we could login with the Windows Hello PIN into the Google account:

Disclaimer: When a passkey existed on this Windows 10 device and you tried to use a new browser, sometimes the passkey prompt didn’t show up in the initial login and instead asked for a password (there was not even an option to take an external passkey via QR code / Bluetooth). Subsequent logins worked again with the passkey created on this device as it seemed that Google checks if it knows the browser for a certain user account.

‍

3.3 Edge cases within the login process

If you want to use passkeys for the first time, some passkeys might have been automatically generated for you by Google (for all your Android devices). By clicking on “Use passkeys” you can start using them:

For other devices, you need to create passkeys manually via “Create passkey”. The next time you log in with one of these devices for which a passkey has been manually created, it will be retrieved and used:

You receive a success message on the device that is linked to the Google account after a passkey was successfully created.

Note that for devices for which a passkey has already been created, no further passkey can be set up.

As mentioned in use case 3, we tested whether a passkey can be retrieved from Apple iCloud Keychain when using an iPhone and non-Apple browsers. If using Chrome as browser, everything works as expected.

When using Firefox, the following bug / error message appeared (only on the first try – later everything work as expected):

When using Edge, a blank white screen appeared, and the user was stuck:

‍

When you are on a non-passkey-ready device (here the Windows 11 laptop is passkey-ready, but we deactivated the passkey-readiness via Chrome DevTools) and try to manually create a passkey in the passkey settings, the following popup appears:

For demonstration purposes and to help other developers build passkey applications smoothly, we set up a virtual authenticator in the Google DevTool WebAuthn settings that mimics a built-in platform authenticator (e.g. Face ID or Touch ID). We used the following settings:

• Protocol: CTAP2
• Transport: Internal
• Supports resident keys: yes
• Supports user verification: yes

With this virtual authenticator active, we created manually a new passkey. This resulted in “Passkey” on the left and increased the “Signature Count” on the right by one.

Still on the same device and with the virtual authenticator active, we logged in with the “virtual passkey” (see how the “Signature count” increased).

When manually deleting a passkey on a platform (see our blog post) or using Chrome DevTools virtual authenticator with settings not applicable to regular passkeys (e.g. with U2F) and having an existing passkey for this platform / device, Google thinks that the passkey still exists and works. When looking for the passkey in the login process, a “Something went wrong” error message is triggered. Clicking on “Try again” ends in an infinite loop. The only way to escape this is by clicking on “Cancel” and using a passkey from a different device or other login method (e.g. password, SMS or push notification).

When logging in on a new Windows device, where no passkey has manually been created the following selection of methods occurs. It even offers the possibility to login with “Windows Hello […]”.

Though, when clicking on this option, the system asks you to use your security key (which most non-technical users do proably not understand). This can be quite confusing.

4. Conclusion

Google is the largest company so far that rolled out passkeys for every user and on every platform. With focus on educating the user (e.g., by dropping the term “passkeys” at important parts), great UX and solutions to overcome the current drawbacks of passkeys, like cross-device processes, lack of sync options on Windows, Google provides in our opinion the best passkeys implementation. Only the sign-up process was completely neglected, as users still need to set a password if they want to create a new Google account, as well as Conditional UI not rolled out yet. This will probably change soon, as the numbers after the first days have proven that Google is on the right track in term of duration to login and login success rate.

‍