"Sign in with a passkey" button
Passkeys enable sign-in experiences without forms with just a few taps and the device screen lock. Because a passkey contains the user's username and display name, the browser or operating system can display an account selector for the user to pick an account to sign-in with, then unlock the screen to verify. By placing a "Sign in with a passkey" button, a website or application can let the user initiate the flow.
This user experience is recommended for RPs that are certain they have only passkey users. If an RP has users without a passkey, they still need to let the users sign in with other methods such as username and password with a form. For such cases, we recommend Passkey autofill suggestions in form fields.
Passkey autofill suggestions in form fields
Passkey-based authentication can be offered via a simple "Sign in with a passkey" button. However, if there are some users with passwords, the RP must offer a sign-in form for those users too. To support both types of users, a username and password form can be used instead which will allow the user to see autofill suggestions for both passwords and passkeys (if available). This also frees users from having to remember if they use a passkey or password.
With this setup, a user sees an account selector as soon as they place a cursor to a form field. When selecting an account, if the account is password based, it autofills a username and password field. If the account is passkey based, it immediately asks the user to unlock the device and attempts to sign them in.
This user experience is suitable when an RP is in transition from password-based or multifactor authentication to passwordless authentication using passkeys.
Learn how to build this user experience:
Reauthentication is a common user experience when a user is already signed in, but needs an additional authentication because a session has expired or because the user is about to perform a sensitive operation, such as adding a shipping address or making a purchase.
In password-based authentication, a user would be asked to enter their password to reauthenticate, but with passkeys, the RP can simply ask to unlock the device to reauthenticate.
This quick authentication ensures that the same user is still in front of the device so it's safer to proceed.
Learn how to build this user experience:
- Build your first WebAuthn app (codelab)
Sign-in with a phone
Passkeys are synchronized across devices that are part of the same ecosystem. For example, if a user creates a passkey on Android, it's available on all Android devices as long as the user is signed in to the same Google account. However, the same passkey isn't available on iOS, macOS or Windows, even if you're using the same browser, like Chrome.
A user can use a passkey on their phone to sign in on other devices by scanning a QR code, as long as the phone is near the laptop and the user approves the sign-in on the phone. This works across different operating systems and browsers.
Let's say a user has an Android device and created a passkey on a website via Chrome. The passkey is saved and synced among Android devices, but not other ecosystems. When the user tries to sign in to the same website on macOS 13 Safari, there are no passkeys saved on the Mac. The user can still use the Android device to sign in by selecting to use a passkey from a second device. Safari shows a QR code that the user can scan using the Android phone, select the passkey and verify with their screen lock. A one-time passkey signature is transferred back to Safari on the Mac, which the website then uses to sign the user in. The two devices verify that they are in proximity with each other using Bluetooth.
This cross-device, cross-operating-system mechanism of passkey authentication is standardized under FIDO and available in Chrome and Safari with other browsers to follow. There is no additional work needed to enable this user experience. It is automatically enabled when developers follow the "Sign in with a passkey"-button approach or the passkey-autofill approach outlined above.