Passkeys are a modern and secure way for users to authenticate. Every user login uses public key cryptography, where devices generate a distinct keypair for each server origin. Only signed material and a public key are sent to servers. Passkeys provide these security benefits:
- Cryptography-backed user authentication;
- Phishing resistance;
- Server breaches cannot reveal user credentials.
The most mainstream and easiest option to use is “platform” passkeys that are provided by up-to-date versions of the main desktop and mobile operating systems. The browser and operating system work together to ensure a modern user experience. The user simply provides a gesture to prove their presence, then logs in to your app in the same way as they would log in to their device. Typically, this is a PIN or biometric (a fingerprint, for example). The underlying platform then does the cryptographic work.
When I first used passkeys, I liked the security and user experience, but I felt passkeys had too many open issues to be used in a production solution. Recently, as I learned more about passkeys, I have changed my thinking. Now I believe you can easily get past any usability and reliability concerns. Here are the high-level steps I recommend to enable you to go live with passkeys.
1. Identify Risks
I am always suspicious of new technologies since unidentified technical risks can sometimes block business delivery. For example, if a solution is insecure, unreliable or has a poor user experience, you typically cannot use it in production. Without care, these problems are discovered late in the development process.
When I first used passkeys, I had many concerns related to reliability. The “happy path” was very attractive, but there were several scenarios that would happen frequently in everyday use that might result in users being unable to log in:
- Some users may run an old operating system and be unable to use passkeys.
- Some users may not want to use passkeys yet.
- A user could register a passkey on one browser and then use it on another.
- A user could register a passkey on a smartphone and then lose the smartphone.
- A user could register a passkey on a laptop and then get a laptop upgrade.
- A user could register a passkey on a work PC and then try to log in on a home laptop.
2. Understand Technical Limitations
Using passkeys consists of two steps. First, the user registers at a server. This creates a keypair and provides the public key to the server. Ideally, a platform passkey is meant to be used on one device and is then also available on any other device. Yet, due to current technical limitations, this is not the reality.
Consider a user registering a passkey in the edge browser on a work Windows computer. The user then tries to use the passkey on their home MacBook on the Safari browser. The existing passkey cannot be used since there are limitations on the synchronization options that are currently supported.
Or, consider another user who registers a passkey on their Android device and tries to use the passkey on their iPad. The existing passkey can be used but only if a technique called cross-device authentication is used, which involves scanning QR codes across devices. Some users may find the experience confusing and be unable to log in.
In my initial thinking, passkeys had three main problems. First, you cannot rely on them to work on older operating systems or browsers. Second, the user may lose their passkey. Finally, passkeys have portability problems.
3. Overcome Blocking Issues
My thinking changed as I saw that you can overcome these problems with two main steps. First, provide a choice of authentication options for users so that no one is blocked. Second, enable users to recover by registering a new passkey. That is, only the user identity needs to be portable, not the actual passkeys.
In a reliable passkeys design, the server allows storing multiple public keys against each user account. To register a passkey, the user must authenticate first. This process can be repeated if the user needs to recover it. A convenient authentication method can be used, such as email verification. Or you could require stronger authentication to register a passkey, such as proof of a government ID.
The preferred way to integrate passkeys is within an OAuth 2.0 architecture. You then receive a tested passkeys implementation. As well as implementing the cryptography for you, the authorization server should also support multiple passkeys per user and follow passkey UX recommendations. After passkey logins, your apps will also continue to receive correct access tokens to send to their APIs.
Conclusion
Passkeys have some technical limitations, which will be ironed out over time. Users are also becoming more accustomed to the passkeys user experience. Yet you need to use a passkeys implementation that provides the correct reliability.
If your apps use password logins today, you should upgrade to passkeys in 2024. They enable cryptography-backed user authentication with a slick user experience. Passkeys could be used for both general internet users and for higher-security use cases.
To learn more about passkeys, watch our webinar “Passwordless Authentication: How to Migrate from Passwords to Passkeys,” available on demand.
Some additional learning resources include:
