FIDO authentication with passkeys

Introduction

The FIDO (Fast IDentity Online) authentication standard defines a fast and secure authentication mechanism for users to access websites and applications.

The FIDO Alliance, with representatives from a range of organizations, develops open and scalable technical specifications that allow people to access websites and apps through a common protocol. This means any company can use FIDO standards to implement technologies, like passkeys, for secure authentication.

A passkey is a FIDO login credential, tied to an origin (website or application) and a physical device. Passkeys allow users to authenticate without having to enter a username, password, or provide any additional authentication factor. This technology aims to replace passwords as the primary authentication mechanism.

Why does secure authentication matter?

Passwords have been used for authentication in computing for decades. However, password-based authentication is not the most secure option for authentication, as databases can be breached and passwords can be phished.

Many users log in to different websites using the same passwords. This means when one website is breached, every other account that uses the same password is at risk. So even if you've built a secure password system, people are still at risk when a password is their only protection.

Some sites and applications request two-step verification by requesting a second credential that is delivered via SMS, email, application, etc. While this is more secure than just using a password, this method of two-step verification is still vulnerable to phishing, because the user can be convinced to enter their two-step verification details into a malicious website.

How does FIDO create stronger security?

FIDO-based authentication removes many of the problems that stem from password-based authentication, and from authentication that uses traditional second-steps. In particular:

  • FIDO authentication uses public key cryptography.
  • FIDO helps to ensure that the credentials aren't shared with malicious parties or other parties that do not own the credential

Public key cryptography reduces the threat from potential database breaches. The user registers with a single origin (a site or application), which generates a public-private key pair on the user's authenticator (a physical device). The user's public key is stored by the origin's server, but this alone is useless to an attacker. An attacker cannot derive the user's private key from the data stored on the server, which is required to complete authentication.

With FIDO, the user is not responsible for confirming that a website or application is actually who they say they are. Further, the user isn't responsible for ensuring credentials aren't used in the wrong places. FIDO binds each credential to a particular origin, which means the device (not the human) is responsible for correctly identifying the website or application.

For example, let's say the user is attempting to log into example.com. If the user requests the credential owned by example.com on phishing-example.com, the authenticator will reject the request thus protecting the user. The authentication process makes it very difficult for phishing websites or apps to obtain verification meant for other origins.

Overall, FIDO and passkeys allow you to deploy stronger authentication that is still usable and easy for most users.

Demo

What are passkeys?

A passkey is a digital credential that adheres to the FIDO and W3C Web Authentication (WebAuthn) standards. Similar to a password, websites and applications can request that a user create a passkey to access their account.

Passkeys rely on unlocking a device to verify a user's identity. This may be performed with a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern. A user must first register with the origin, to generate their passkey (a public-private key pair).

When they return to the website or app to log in, the user may take the following steps:

  1. Go to the application.
  2. Click Sign in.
  3. Select their passkey.
  4. Unlock the device to complete the login.

The authenticator generates a signature using the private key. This signature is used to verify the login credential between the origin and the authenticator, using the public key and without revealing the private key.

A user can sign into services on any device with the help of a passkey, regardless of where the passkey is stored. For example, a passkey stored on a mobile phone can be used to sign in to a website on a separate laptop.

How do passkeys work?

Passkeys are created and synchronized through the operating system. Some operating systems may allow automatic synchronization of passkeys between the user's devices, such as an Android phone and ChromeOS device which are signed into the same Google account.

While passkeys are tied to operating systems, a user can use passkeys from their phone when logging into a laptop. As passkeys are built with FIDO and W3C standards, all browsers can adopt them. For example, a user visits site.example on their Chromebook. This user has previously logged into site.example on their iOS device. The user will be prompted to confirm their identity on the iOS device. Typically, site.example will create a new passkey for the user's Chromebook so that for future logins, the phone is no longer required.

Passkeys are end-to-end encrypted, which means that even though Google is responsible for synchronizing them to different Android devices, Google cannot read the passkey or otherwise know that data.

Authentication process

A representation of what the authentication window may look like.

To implement passkeys on a website or app, it's important you familiarize yourself with the following:

  • Authenticators are user-owned, physical devices which hold the user's passkeys and can identify the user.
  • The relying party is your website or app, composed of a front-end application and back-end server.
    • The front-end application calls APIs to interact with the authenticator and initiate the authentication process.
    • The back-end server retrieves the cryptographic objects produced by the authenticator and verifies them.

For example, let's say a user wants to purchase a pair of shoes from a store at shoes.example (the relying party). The user has already registered for an account on shoes.example, using their Android phone with a biometric sensor. The user logs into shoes.example on their Android device by unlocking their device. Then, shoes.example verifies the user's cryptographically signed login credential against the known public key for that user to confirm the user's identity is accurate.

Authenticators

Authenticators are FIDO-compliant devices which are used to confirm a user's identity. This includes special purpose devices (FIDO security keys), as well as mobile phones and other computers which meet the authenticator requirements. Authenticators perform the cryptographic operations described in the FIDO and WebAuthn standards.

The device has two roles, for registration and authentication:

  • When the user registers with a relying party, the device generates a unique public-private key pair. This includes the user's phones and computers.
  • When the user logs into the relying party in the future, the device generates a signature using the private key.

Both operations are performed when the user proves possession of the authenticator. This key pair is registered with a specific origin, and can only be used by the exact origin. If a user lands on a phishing site the credential will be unavailable.

FIDO-compliant devices

The most common authenticators are:

  • Platform authenticators: these are built into smartphones and computers. Platform authenticators use a biometric sensor (such as a fingerprint sensor or a camera with facial recognition), a PIN, or pattern. Because the authentication interaction is completed by unlocking the device, this proves in a single step that both the user has possession of the device and can confirm their identity with their unique biometrics.
  • Security keys: these are commonly USB devices with a button to press to indicate authentication. When used with a password, security keys can provide a possession factor for two-factor authentication. The most common example of this is a Titan Security Key or a YubiKey.

Front-end

Applications use client-side APIs, like WebAuthn and FIDO2 for Android, to create and verify user credentials with the authenticator.

The application passes a cryptographic challenge, generated by the back-end server, to the authenticator. The application sends the authenticator's response to the server for validation, which takes action based on that validation.

Back-end

The server stores the user's public key credential and account information.

On registration and authentication, the server generates a cryptographic challenge. This challenge verifies that the signature issued by the authenticator, confirming if the user is who they claim to be.

Frequently asked questions (FAQ)

Who supports passkeys?

Because passkeys are based on FIDO standards, they work on Android and Chrome, along with many other popular platforms and browsers such as Microsoft Windows, Microsoft Edge, MacOS, iOS and Safari.

Refer to the documentation provided by these platforms to confirm the current state of availability.

On Android, we aim to have passkey support available to developers towards the end of 2022.

What happens if a user loses their device?

Passkeys created on Android are backed up and synced with Android devices that are signed in to the same Google Account, in the same way as passwords are backed up to the password manager.

That means a users' passkeys go with them when they replace their devices. To sign into apps on a new phone, all users need to do is unlock their phone.

Can a user use a passkey on their phone to sign in on a friend's device?

Yes. Users can set up a "one time link" between their phone and someone else's device for the purposes of signing in.

Next steps

Take a codelab:

Learn more about: