What are Passkeys?

The Passkeys Home Page provides a visual overview of passkey related behavior. This page takes a closer look at the main behaviors enabled by using passkeys as an authentication method.

Passkeys are public key credentials for user authentication, based on WebAuthn specifications from the FIDO alliance. See the WebAuthn Overview article for an introduction. Passkeys are a subset of WebAuthn credentials. Passkeys use multiple authentication factors, and can be synchronized or used across multiple devices. In many use cases no other authentication factors are needed.

One way to get started with passkeys, and review the user experience, is to use an online demo website. Examples are passkeys.io, which enables you to sign up with your own email, then delete your account once finished. Alternatively, passkey.org enables you to sign up with a dummy username.

How Passkeys Work

Users who authenticate with passkeys perform two ceremonies, with only simple gestures. Lower level security is implemented by an entity called an authenticator in WebAuthn terminology. Example authenticators are browsers, operating system services or external devices such as key fobs.

First, the user chooses to create a passkey and registers it with the application. This stores a private key in the authenticator, and the corresponding public key in the application's backend. Then, on all subsequent logins, the user approves use of the passkey. The application's backend then receives data signed with the private key, which it verifies using the corresponding public key.

Since users never enter their passkeys directly, the passkeys cannot be captured via phishing attacks. Also, WebAuthn ensures that a distinct keypair is used for each website or application with which the user interacts. So, even if the private key for one application is somehow revealed, it cannot be used elsewhere. Since servers only store public keys, and authentication requires proof of ownership of the private key, server breaches can never reveal user credentials.

With passkeys, the primary authentication factor is the private key, which provides a possession factor. The second factor can be a biometric, such as face or fingerprint recognition, to represent an inherence factor, or an input value, such as the device's PIN or password, to represent a knowledge factor. Read more about multi-factor authentication and its terminology in the Introduction to MFA.

Using Platform Passkeys

A popular way to use passkey authentication is to use those from cloud providers, such as Google passkeys and Apple passkeys, where the user needs only to have an account with the cloud provider. When the user first signs in they are prompted to create a passkey. As an example, the prompts in Chrome and Safari browsers look similar to the following screenshots:

The user is then prompted for a biometric, or device password as a second factor, and the passkey is created. On all subsequent logins the user simply provides their second factor in order to use the passkey again.

When relying on platform support of passkeys, the user can choose to back the keys up using a cloud service. For example, Google does this using the Google Password Manager, and Apple uses the iCloud Keychain. The passkey can then be downloaded to the user's other devices, to prevent them needing to re-register, when using the same applications on those devices. The passkey is also encrypted end-to-end, so that no intermediate party can access it.

Using Cross-Device Authentication

Passkeys are not limited to the platform. There are other ways to log in with passkeys, as illustrated by the following Chrome and Safari screenshots. One of these is cross-device authentication (CDA), by choosing the option to login using a smartphone or tablet. In this flow, the browser displays a QR code that the user can scan with their mobile phone’s camera. Then the devices communicate via Bluethooth to let the user sign in with the passkey from the mobile device.

Using External Passkeys

One security concern with platform passkeys is that if the user's account is compromised, and passkeys are backed up to the cloud, a malicious party might gain access to the user's passkeys. To protect against this, users should ensure strong device and account authentication.

An alternative option is to log in using a FIDO security key, configured with a PIN. These produce device-bound passkeys where the private key is guaranteed to never leave the device. As a backup solution users can keep a secondary FIDO security key, with additional passkeys for each of the applications that they have registered with.

The user can take their security key with them and use it at many devices, such as by plugging it into a USB socket or using near field communication (NFC) on a mobile device.

Using Passkeys in Native Mode

For a purely native user experience in mobile apps, integrate passkeys outside the system browser with native SDKs that call native APIs. The operating system provides these APIs, and also the system screens for the user interaction.

Passkeys in an OAuth Architecture

When a client uses OAuth, it runs an OpenID Connect Code Flow to begin passkeys authentication. Doing so outsources the complexity to the authorization server, which implements the passkeys authentication, in a way that can be used by multiple clients. Once passkeys authentication is complete, each client then receives a set of OAuth tokens and can call its APIs with the correct security.

In the OpenID Connect Code Flow, the authorization server redirects the browser to authentication forms that implement the required JavaScript code for the passkeys authentication. The passkeys form invokes the WebAuthn API of the browser, that generates a signature with the private key of the passkey. The form then forwards the signature to the authorization server, which performs the cryptographic verification using the user’s registered public key.

By default, OAuth utilizes the system browser and not native passkey APIs for interactive user authentication. To implement native passkey logins, the authorization server can implement OpenID Connect in an API driven manner, and provide a client side SDK. The SDK can avoid opening the system browser, and instead call native WebAuthn APIs:

Passkeys in the Curity Identity Server

The Curity Identity Server supports both of the above flows. The Passkeys Tutorial shows how to configure passkeys authentication. For browser use cases, simply enable the authentication method for clients. You can also implement Native Passkeys in Mobile Apps, using the Hypermedia Authentication API (HAAPI) and its client SDK. In this case the Curity Identity Server also hosts the required mobile asset files.

How to Integrate Passkeys

If you are already using an OAuth architecture, adding support for passkeys authentication should be straightforward. This can be done with full reliability and considerable benefits in user experience. You do however need to understand some technology limitations and how to manage them. The Passkeys - Design your Solution article summarizes the main behaviors and provides some recommdations.

Conclusion

Passkeys provide a cutting edge blend of strong security and modern usability. We recommend that you support passkeys authentication in your applications, since they eliminate password related attack vectors, which benefits both users and organizations. Implement passkeys authentication in the context of an OAuth flow, so that, once authentication is complete, API access continues to work in the standard way.