Passkeys 101: what they are and how they work

People have been proclaiming the death of passwords for over a decade. That's fair: passwords kind of suck. They're too often easy to guess and reused around the web, making it easy for bad actors to hack into consumer accounts. Solutions like password managers and even two-factor authentication are helpful but don't fully solve the problem.

Passkeys finally help solve the issues with passwords in a sustainable way by offering a user friendly and secure alternative for customer authentication. Passkeys are built on top of WebAuthn, part of an industry standard to eliminate passwords and make authentication more secure while keeping things user friendly.

Read on for a high level understanding of what passkeys are, how they work, key terminology, and what you need to keep in mind for implementing passkeys on your own sites. The specifications are open source if you want to dive deeper, but this article will summarize the concepts to get you started on your passkey implementation journey.

What are passkeys?

Passkeys are a standardized form of passwordless authentication that use a combination of a browser API and an authentication device like your phone or computer to offer secure, site specific credentials. For example, if you generate a passkey to log into acmeinc.com, the passkey only works on acmeinc.com, which helps prevent phishing attacks and account takeovers.

Passkeys also have built-in multi-factor authentication in the form of device possession and a user gesture like a fingerprint scan or PIN. Passkey synchronization with passkey managers like Apple or Google allows users to sign into websites on multiple devices or to restore access if they lose an authenticator. Passkeys are built on top of standards developed by W3C and FIDO Alliance including WebAuthn and the Client to Authenticator Protocol (CTAP), which makes them a reliable form of secure authentication.

How do passkeys work?

Passkeys use public key cryptography to generate an authentication key pair (a public key and a private key) also known as a credential. Public keys are stored on a backend server (either the relying party server or their authentication provider's server like Twilio Verify) while private keys are stored on the device where they were generated and in the passkey manager like the iCloud Keychain or Google's passkey manager.

There are two flows for using passkeys: registration and authentication.

How passkey registration works

To register a passkey, start with an authenticated user then call the navigator.credentials.create browser API. This will prompt the user to select an authenticator and passkey manager. The browser function returns a public key credential . Send the returned credential to your application backend to use in subsequent authentications.

You can simulate passkey registration with a few lines of code in the browser. Open up your developer console while on a Twilio.com page and try the following:

This code will throw an error if you try to run it on a domain other than Twilio.com because the relying party is set to twilio.com. This keeps credentials scoped and makes the passkey phishing resistant.

Learn more with this interactive guide, including detailed parameter explanations, at webauthn.guide/#registration .

The browser API doesn't do much good unless the public key is also stored with the server so the relying party can issue authentication challenges; in other words you won't be able to magically log into a Twilio account with just this browser request.

How passkey authentication works

To sign in with a passkey, issue an authentication challenge (a random string) from the server then fetch the passkey using the navigator.credentials.get()  browser API. The browser will prompt the user for something like a fingerprint or a PIN to confirm both device ownership and the biometric or knowledge secret built into the authenticator. The browser function returns an assertion containing the signature made with the private key: this is how the private key is used to authenticate without being transmitted in the authentication request. Finally, send the signature to your application server where your application will validate the signature with the public key and approve or deny the authentication.

Like registration, you can simulate passkey authentication with a few lines of code in the browser. Head back to your developer console while on a Twilio.com page and try the following. If you closed or refreshed the page since you registered the passkey, leave off the optional allowCredentials line which tells the browser which passkey to look for.

Learn more at webauthn.guide/#authentication or try it out for yourself with this demo at twilio-verify-passkeys-demo.vercel.app/.

Different types of passkeys

The two main categories of passkeys are:

1. Synced passkeys backup private keys to a passkey manager like Apple iCloud Keychain, Google Password Manager or Windows Hello. The benefit of a synced passkey is multi-device authentication and fallback or account recovery options. Synchronization is a tradeoff to improve long term usability.

2. Device bound passkeys use private keys that never leave the originating device. A relying party could require device bound passkeys for strong assurance that the user has possession of the device where the passkey was created. This may be required for higher risk individuals or accounts.

Why are passkeys a better authentication option?

Passkeys offer the elusive promise of so many authentication solutions: better security without sacrificing usability.

Security benefits of passkeys

• Unique. Unlike passwords, you can't reuse passkeys since each passkey is generated per-site. This limits credential stuffing attacks leading to fewer account takeovers.
• Phishing resistant. Because passkeys are tied to a domain, phishing attempts to trick you into signing into a look-alike authentication request would fail.
• Reduces hacking targets. Since only public keys are stored on a company's servers, a data breach is no longer as enticing for hackers or harmful to users since public keys are useless without also having the private keys.

Usability benefits of passkeys

• Intuitive. Passkeys are built into things we already have and don't require a separate app like TOTP or a separate device like a Yubikey. The experience of using passkeys is familiar to end users, making it feel like they're unlocking a phone. This means the barrier to entry is low and promises high potential for adoption.
• Fast. Using passkeys is up to 40% faster than typing in a password or even a 4-6 digit one time passcode.
• Compatible. Passkeys can also perform cross-device authentication regardless of ecosystem or platform. On top of keeping authentication fast, this means fewer account recoveries and locked out users.

Account recovery with passkeys

Because passkeys are synced to a provider, account recovery is built into the design. As Apple notes on recovery security , "Passkey synchronization provides convenience and redundancy in case of loss of a single device." Users can recover their iCloud Keychain or Android passkeys but other fallback options are still wise. Best practices for account recovery include registering fallback methods like TOTP, recovery tokens, or even SMS.

Current limitations of passkeys

The main limitation of passkeys is adoption.

Websites and applications need to switch users to passkeys in order to fully realize a passwordless future. While many users have platform authenticator compatible devices like smartphones, many do not. Altertnatives like Yubikeys are expensive and only realistic for enthusiastic security users. Because of this, the industry will need to continue supporting alternative forms of authentication for a while. Luckily browser support is nearly complete - around 95% as of 2024 .

Finally because passkeys are still new, implementation may be more challenging: there is still limited documentation and sample apps and nascent library support. Cryptography is also intimidating which is why using an authentication provider on the server side like Twilio Verify Passkeys can help ease the implementation hassle.

How to implement passkeys

Verify Passkeys will provide the server side tools you need to easily integrate passkeys into your consumer authentication with a simple API. Sign up here for early access and to be notified when Verify Passkeys are self-serve .

Passkeys takeaways

Passkeys finally offer a usable and secure option for both end users and the companies implementing passwordless authentication. As we work towards widespread adoption to eliminate passwords, you can start offering this authentication method to delight your security conscious users while increasing your own security posture.

Follow the Twilio Passkeys documentation for updates or check out our additional authentication channels available in the Verify API in the meantime. For more passkeys information, check out the following resources:

• Official WebAuthn spec
• FIDO Alliance
• webauthn.guide
• Passkeys live demo and example Python code of Verify Passkeys

I can't wait to see what you build and secure.

Appendix: Passkeys Glossary

The world of passkeys has a lot of jargon and terminology. Here are a few key definitions:

WebAuthn

Shorthand for "web authentication", WebAuthn is a standardized browser API with per-site scoped credentials. Each credential is a public-private key pair that can be used for strong authentication instead of passwords. End users only need access to the device ("authenticator") where the key pair was registered in order to authenticate. Passkeys are essentially a rebranding of WebAuthn with the added private key backup.

Authenticator

Authenticators create the credential key pair and store the private key. There are two main categories of authenticators:

• "Platform authenticators" - built into computers and phones like Windows Hello or Face ID
• "Roaming authenticators" - external security keys like Yubikeys

FIDO2

The FIDO Alliance is "an open industry association with a focused mission: reduce the world’s reliance on passwords." FIDO2 is the alliance's passwordless authentication spec that combines WebAuthn with the platform authenticator devices many users already have. Prior to FIDO2, end users needed a special device to take advantage of WebAuthn which limited adoption potential.

CTAP2

The Client To Authenticator Protocol defines how the authenticator (e.g. Yubikey, Face ID, or Windows Hello) talks to the client (a browser or operating system) for authentication. The protocol uses underlying transports like NFC or Bluetooth to communicate with the browser. CTAP2 is the latest version that works with WebAuthn and passkeys.

Relying party (RP)

The relying party is the business or website performing the authentication. For logging into acmeinc.com with a passkey, Acme Inc. would be the relying party.