Common Developer Misconceptions About Passkeys

Passkeys replace passwords for user authentication, provide a better user experience, offer more security and phishing resistance. However, there are some subtle nuances that can confuse developers. Let’s dig into some of them.

This article is not an introduction to passkeys. It assumes that you, as a developer, have some general knowledge about them and are looking for clarification about some confusing concepts.

If you are new to passkeys, you can learn more by visiting learnpasskeys.io.

Where Are the Specs for Passkeys?

The term passkey is a common noun in the same way that password is. It's not a product name, and it's not a formal technical name such as ID token or JWT. However, a widely accepted definition from the FIDO Alliance defines passkeys as "a replacement for passwords that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices".

The FIDO Alliance also provides a technical definition of passkeys: "passkeys are FIDO credentials that are discoverable by browsers or housed within native applications or security keys for passwordless authentication".

In other words, while the term passkeys is common in everyday conversation, it identifies something that is formally defined by a set of technical specifications: FIDO2/WebAuthn. Keep reading to learn a bit more about these specifications.

By the way, you should not capitalize the term passkey as if it were a product name. It should follow the capitalization rules of any common noun, as with the term password.

Passkeys, FIDO, and FIDO2

Some recurring terms around the passkey definition may confuse many developers: FIDO, FIDO Alliance, FIDO2. What are they? What is the relationship between them?

FIDO stands for Fast IDentity Online and refers to an initiative to solve the password problem in user authentication. The same name is used to identify the set of standards that allow user authentication through cryptographic keys, although the correct name should be FIDO Authentication.

FIDO Alliance is the name of the open industry association that carries on the Fast IDentity Online (FIDO) initiative. Among its members, you can find Apple, Microsoft, Google, and Amazon.

FIDO2, or rather FIDO2 Authentication, is one of the FIDO Alliance's technical specifications for enabling passwordless strong authentication. Specifically, FIDO2 Authentication is the set of standards that passkeys rely on. FIDO2 Authentication includes the W3C WebAuthn specifications and the FIDO Client to Authenticator Protocol (CTAP) specifications. These are commonly referred to together as “FIDO2/WebAuthn”.

The WebAuthn specification defines how web-based relying parties can interact with passkeys in a browser, while CTAP allows the implementation of Cross-Device Authentication (CDA), i.e., it enables communication between a client/platform and an external authenticator.

Passkeys and FIDO Credentials

The technical definition of passkeys refers to FIDO credentials. What are they?

FIDO credentials, also known as WebAuthn credentials, are cryptographic key pairs based on public-key cryptography and used for authentication. With FIDO credentials, the authentication process is not based on a shared secret, as it happens with passwords. On the contrary, the user shares the public key with the authentication server at the time of registration. Sharing the public key does not compromise the security of the user identity: it's public information that can be shared without any risk. To authenticate, the user must demonstrate that they are in possession of the corresponding private key. This is accomplished by signing a challenge (a randomly generated value) with the private key.

So, the core building block of the passkeys infrastructure is a public-private key pair called FIDO credentials. From a technical perspective, we can identify passkeys with special FIDO credentials. What is so special about these FIDO2/WebAuthn credentials compared to traditional ones? They are discoverable, which means that an authenticator is able to detect the private key associated with an authentication server (relying party) given its domain. This makes the user experience smooth and convenient since they don't even need to send their username to the authentication server.

Passkeys and WebAuthn

You may have heard of passkeys in conjunction with WebAuthn and are wondering what their relationship is. As mentioned earlier, passkeys rely on FIDO2 Authentication, which is based on two specifications: W3C Web Authentication (WebAuthn) and FIDO Client to Authenticator Protocol version 2 (CTAP2). While CTAP2 defines how devices can communicate with external authenticators, WebAuthn defines how browsers can manage FIDO credentials for user registration and authentication.

WebAuthn defines a JavaScript API to allow a website to request the creation of a new passkey and get proof of possession of the private key. By using this API, a website can't access the private key of the cryptographic key pair, but it can request the authenticator to sign a challenge with that private key. This proves that the user controls the private key, which is what proves the user's identity.

To summarize, a passkey is a credential that allows a user to prove their identity, while WebAuthn is a standard API that allows an application to create and use passkeys for sign-in.

Passkeys and Biometrics

A common misconception is that passkeys let users authenticate via their biometrics, such as their fingerprint or their face. While using biometrics is one of the ways to complete the authentication process with the relying party, saying that passkeys let you authenticate through biometrics is not accurate.

The relying party has no access to your biometrics. Your fingerprint and your face data are stored locally in your authenticator device, so the relying party cannot authenticate you based on your biometrics. It authenticates you as the holder of the private key part of your passkey. Biometrics are used locally to let you access your authenticator and prevent a malicious person from using your authenticator. To be precise, a biometrics-based authentication exists, but it is local and does not involve the relying party.

In addition, you are not required to use biometrics to access your authenticator unless the relying party forces this requirement. In some contexts, you can just use a PIN or draw a pattern to access your authenticator. The use of biometrics, PIN, or other interactions with the authenticator is known as an authorization gesture.

Passkeys Are Not Accounts

Another common misconception about passkeys is that they are the same as user accounts. You can find some threads about this confusion all around.

A user account can be defined as the representation of the identity of a user in a given context. For example, your Google account identifies you in the Google ecosystem, i.e., in the set of applications and services that Google provides you. Your Apple account identifies you in the Apple ecosystem, and so on.

To prove your identity to Google when you access one of its applications, you need to provide your credentials, such as a password or a signed challenge, in case you are using a passkey.

Your credential is not your identity/account. It allows you to prove your identity, but it's not the account. You can change your credentials, but your account remains the same.

In the context of passkeys, you can add a passkey to your account. You could even add multiple passkeys to your account. If you remove your passkey (or one of your passkeys) from your account, you are not deleting your account. You are just removing a way to prove your identity.

Think of your passkeys as you think of your passwords.

Passkeys Are Not (Necessarily) Hardware-based

While many FIDO authenticators are based on hardware devices, FIDO2/WebAuthn does not require this. The specifications explicitly say that an authenticator can be implemented via software. This means that the public and private key pair is created by the software and is stored on the file system after encryption.

A software authenticator can be part of the operating system or an independent application. While a hardware authenticator does not allow you to export the private key stored on it, a software authenticator is more flexible. In fact, synced passkeys rely on a software application or operating system subsystem to export their private key to the cloud and then share it with other devices.

Passkeys Are Not Only for the Web

A common misconception about passkeys is that they are meant only for web applications. Perhaps this is due to the fact that WebAuthn is a W3C standard, which essentially involves browsers. In fact, you can use passkeys for desktop and mobile applications, too.

You can use two approaches to get passkey support into your native applications:

• Use the browser to authenticate the user. You can delegate user authentication to an external browser or system webviews. In this case, user authentication relies directly on WebAuthn, as it happens with web applications. After authentication, the user is redirected back to the native application with a token proving it succeeded.
• Use your platform-specific abstraction of the WebAuthn API. Platforms provide you with native implementations to manage passkeys in your applications. For example, you can use Credential Manager to support passkeys in Android and specific APIs for macOS and iOS.

The Role of Authenticators

Authentication using passkeys relies on authenticators, which are hardware or software components capable of managing cryptographic key pairs. You can have two types of authenticators:

• Platform authenticators. These authenticators are integrated into your device or are modular software components running on your device. Usually, they are not removable from your device. Examples of platform authenticators include Google Password Manager, Apple iCloud Keychain, Windows Hello, 1Password, Bitwarden, and Dashlane.
• Roaming authenticators. These are authenticators that can be used on a device other than the one on which the user is authenticating. Examples of roaming authenticators are security keys or smartphones.

While this classification may seem simple to understand at first look, keep in mind that the authenticator type is more a matter of role than inherent characteristics. In other words, a specific authenticator can act as a platform authenticator in one context and as a roaming authenticator in another.

Consider the case of the authenticator embedded in a smartphone. When the user authenticates to an application running on the smartphone, the smartphone's authenticator is a platform authenticator. When the user uses the same smartphone to authenticate to an application running on a laptop via Cross-Device Authentication, the smartphone is a roaming authenticator.

The rule of thumb to determine what is the current role of an authenticator is:

• Has your device a built-in authenticator, and you are using it to access an app or website on the same device? If so, it’s a platform authenticator.
• Has your device a built-in authenticator, but you are using it to let another device access an app or website? Then it’s a roaming authenticator.

As a final note, while as per definition, the authenticator is just the subsystem able to manage cryptographic key pairs, it's common to call the entire device the authenticator. So, don't be surprised if you hear someone say they use their smartphone as an authenticator.

Not All Passkeys Are the Same

You might have heard that there are different types of passkeys, and you may have heard different confusing names for them: single-device, multi-devices, synced, device-bound. Let's try to put order in this naming.

The currently accepted naming for passkey categorization is as follows:

• Device-bound passkeys. These types of passkeys are bound to a single authenticator, i.e., the authenticator that created them. Once a passkey has been created, it cannot leave the device where it was created. As an example, consider a security key: you can't move the passkey created with this authenticator to another device. For a very short period of time, this was referred to as a single-device passkey, but that name is no longer used.
• Synced passkeys. These are passkeys that can leave the authenticator in which they were created and move across devices via the cloud. The passkeys are end-to-end encrypted and synced to all of a user’s devices using the same provider. This enables sharing them with all the devices of a user associated with the same passkeys provider account, such as Apple ID, Google account, 1Password account, Bitwarden account, and so on. For a very short period of time, these were referred to as multi-device passkeys, but that name is no longer used.

Passkeys, Single Sign-On, & C.

You learned that passkeys are a new way to authenticate the user in a much more secure and convenient way than other traditional forms of authentication, first and foremost, username and password. But how does Single-Sign On (SSO) work with passkeys? Can we continue to use one account to access multiple applications, or do we have to create a new passkey for each application while using the same account?

Actually nothing changes when you use and implement SSO in your applications. Passkeys introduce a new way to authenticate a user but do not change how to manage the resulting authenticated session. In other words, once the authentication server has authenticated the user, it can generate the authentication cookie just as it did with password-based authentication. Passkey and SSO can coexist seamlessly.

Similarly, passkeys and OpenID Connect or OAuth 2.0 coexist. There is no overlap. After a passkey-based authentication, the identity provider or authorization server may issue the required tokens as usual.

Curious about how passkeys work? Try passkeys now →

learnpasskeys.io

Summary

Passkey technology is proven and solid, but some internal complexity may lead to some misconceptions. This article went through a few of them, trying to explain how things are. If you have any other doubts about passkeys and the technologies behind them, please leave a comment below.