Google Passkeys: Implement Passkeys Like Google

• Availability since May 3, 2023
• 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

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.

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

Currently, Google passkeys are only available to log into your Google account. 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 use the "Create passkey" button while logged into the Google account or being in the login process, where Google proactively suggest to create a passkey.

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.

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 dont 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.

Google uses the term "passkeys". As with eBay passkeys, the reference is drawn to the underlying concept of biometric authentication, with which the vast majority of users are likely to be familiar. However, 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.

Google puts UX as their top prioritiy. Logically, they follow an identifier-first approach in their sign-up and login process also for passkey authentication. This means that the user provides their login identifier first (e.g. email address), clicks on Continue and then Google's passkey intelligence and device management decides if a passkey might be available or another form of authentication should be triggered. If the passkey is on this device available, then the passkey authentication flow starts. If not, an alternative login is performed after which a passkey creation page is shown to set up a passkey for subsequent logins on this device / ecosystem

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 passkeys 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).

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 with an upcoming Windows 11 update. That means, a new passkey must be created for each Windows device that you want to link to your Google account.

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.

September 2024 Remark: Google has enabled Conditional UI in the meantime

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, its 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, its confusing as youll 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).

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.

Passkeys come in two distinct types which are device-bound and synced passkeys. Device-bound passkeys are tied to a specific device, meaning that the passkey can only be used on the device it was generated on. Synced 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 dont need to enrol each device.

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.1 Use case 1: iPhone Safari passkey login (initial passkey setup)

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 doesnt 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:

3.2.2 Use case 2: Android Chrome passkey login

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 couldnt 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 couldnt 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.

3.2.3 Use case 3: MacBook Chrome passkey login

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 youve 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 its the one from the iCloud Keychain.

3.2.4 Use case 4: MacBook Safari passkey login

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 didnt 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.

3.2.5 Use case 5: Windows 11 Chrome passkey login

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.

3.2.6 Use case 6: Windows 10 Chrome passkey login

When trying to access the Chrome account from another Windows device (here Windows 10), initially, youre 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 didnt 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.1 Edge case 1: Manual passkey setup

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.

3.3.2 Edge case 2: iPhone login with non-Apple browsers

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:

3.3.3 Edge case 3: Non-passkey-ready devices (manually deactivated)

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:

3.3.4 Edge case 4: Google Chrome DevTool WebAuthn virtual authenticator

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).

3.3.5 Edge case 5: Manually deleting a passkey

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).

3.3.6 Edge case 6: First login with Windows Hello (no passkey available)

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.

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.