What are Passkeys?
On this page
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, like email or SMS verification, 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.
Support for passkey features in operating systems and browsers is evolving. The browsers with the best current support for passkeys are Chrome and Safari. On mobile platforms, passkey support is available from Android 9 and iOS 15, if mobile builds are produced using the latest SDKs. The following links provide further detail on supported devices:
Implementing Passkey Authentication
To implement passkeys authentication, applications can use the WebAuthn API. There are a number of integration guides available, and some are listed here:
Native APIs require developers to bind the app to the server domain that is used to validate passkeys. The native guides describe how to enable this, by hosting a mobile assets file. This is called
assetlinks.json on Android, or
apple-app-site-association on iOS.
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.
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.
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.
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.Start Free Trial