Skip to main content

Sign In with a Passkey

Overview

Topics: consumer, passkey, WebAuthn, sign-in
Customer journey Awareness > Consideration > Enrollment > Management > Authentication
Created: 6 May 2023

Allow people to sign in with a passkey and other methods.

Add sign in with a passkey

  • Enable autofill by adding autocomplete=”webauthn” to the username input field.
  • Support graceful fallback to other sign-in methods. Allow people to enter another identifier to sign in or create an account.
  • Our research explored participant success and satisfaction with a dedicated Sign in with a passkey link, buttons, and autofill. Our testing indicates that autofill ensures the highest success for people to sign in with a passkey.

Outcomes

UX architecture diagram of the workflow for signing in.

Flow: schematic

Flow: video

Flow: Android prototype

tip

To view full screen, hover over the prototype, then select the expand icon.

Flow: iOS prototype

tip

To view full screen, hover over the prototype, then select the expand icon.

Content

Learn which user-tested button labels and phrases help people. Copy and edit content examples to suit your needs.

With passkeys, you don’t need to remember complex passwords.

What are passkeys?
Passkeys are encrypted digital keys you create using your fingerprint, face, or screen lock.

Where are passkeys saved?
Passkeys are saved in your credential manager, so you can sign in on other devices.

UX Research

On the homepage, offer one affordance for both sign-in and account creation. The research indicated that the action of creating an account was more discoverable on DigitalBiz when the sign-in and account creation options were combined, rather than surfacing the account creation option after people opted to sign in. In addition, some participants reported that occasionally they are uncertain whether they have an account and a multipurpose button serves their needs.

Autofill usability

The research explored participant success and satisfaction with a dedicated Sign in with a passkey link, buttons, and autofill. Our testing indicates that autofill ensured the highest success for people to sign in with a passkey. Autofill makes passkey sign-in fast and efficient. The research indicated when autofill was enabled, participant responses to signing in with a passkey were overwhelmingly positive. The most frequently used adjectives to describe signing in with a passkey with autofill were simple, fast, efficient, and seamless.

A small percentage of browsers, such as Firefox, do not currently support autofill. Also, some people might have turned off autofill in their browser settings and cannot take advantage of the outstanding usability of passkey sign-in with autofill.

Dedicated button usability

User research shows that using a dedicated Sign in with a passkey button is not as effective as autofill. Many people do not discover a dedicated passkey button. Additionally, many people do not remember creating a passkey and do not search for a dedicated passkey button. While some use cases might warrant a dedicated passkey button, it is advised to avoid it.

Identifier (username) first usability

If autofill is not available to the person who is signing in and an organization does not want to add a dedicated passkey sign in button, then the organization might choose to allow people to submit their identifier (username). The organization can then give the option to continue with a password or passkey.

Continue with password

For example, Apple uses this approach with its iCloud service.

note

In the Apple example, if the user chooses to continue with the password, then the user is presented with multiple additional security steps to gain access to their account.

The additional steps you choose to implement should match your organization's unique business and security requirements.

Continue with passkey

If the user submits their identifier (username) and then chooses the passkey option, the user might or might not have a passkey on that device for that particular user.

  • If they have a passkey available to use on their device they can use it to sign in.
  • If they have a passkey available on another device, they can use cross-device sign-in to sign in.
  • If they do not have a passkey available on their device or on another device, then they can be redirected to sign in another way. For example, in this scenario KAYAK allows you to sign in with a one-time passcode. In another example, Google allows you to sign in using many different ways.
note

The other ways you allow people to sign in should match your organization's unique business and security requirements.

Roll-out strategy

  • For service providers who choose a phased rollout strategy which initially only allows people to create passkeys from their account settings. Then, as data is gathered about the passkey sign-in experiences unique to their needs, they can expand the number of places where a passkey can be created, including during account creation.
  • The service provider should develop a communication plan to educate people about the availability of passkeys and their benefits. To reach people effectively, the service provider can leverage multiple communication channels, such as in-app notifications, email, and online help resources, that align with their unique security and business goals.

Ecosystem

  • Passkeys might require specific hardware or software support on user's devices. Ensure that users are aware of the compatibility requirements for using passkeys and provide guidance on compatible devices and browsers.
  • In the native mobile app context, signing in with a passkey differs from the biometric sign-in experience that has existed for many years. Signing in with a passkey requires an additional tap.

Security

DigitalBiz gracefully falls back to an email OTP. The graceful fallback option you choose should match your unique security and business goals. Plan your UX in accordance with your unique security and business needs. The guidelines focus on UX concepts that are unique to FIDO with synced passkeys. You will see various forms of identity proofing and non-FIDO authentication examples throughout this work. The guidelines do not intend to prescribe security guidelines for identity proofing or other non-FIDO authentication mechanisms as they are unique to each relying party (RP) and based on their own unique business needs and security policy.