Our Take on Passkeys

"When the student is ready, the teacher will appear"

— Tao Te Ching

"Passkey" is the shorthand for FIDO multi-device credentials, a new technology that makes it convenient to use FIDO's phishing-resistant authentication methods and ceremonies across multiple devices.

We believe that passkeys offer a viable, phishing-resistant alternative to passwords that solves end-user friction for consumer applications in particular, and we are committed to making it easy for developers to offer that experience to their users. Passkeys might also introduce challenges for solutions relying on FIDO's platform authenticators as they are implemented today, typically in the workforce and mission-critical solutions: as an industry, we'll need to find ways to reap the advantages of this new technology while minimizing the drawbacks.

The Starting Point: FIDO's Platform Authenticators

Passwords are a classic example of how civilization will, sometimes, get stuck on a local maximum. Intuitive, portable, and (in the naive case) easy to use, shared secrets have been used to protect information and resources since at least Roman times.

Unfortunately, the sheer number of accounts everyone needs to juggle to participate in modern life exacerbates the shortcomings of this method, up to and including all the ways in which passwords can be stolen by bad actors, remotely and at scale.

The FIDO Alliance, a group of industry leaders, was formed to create and promote the adoption of phishing-resistant tech that could be a viable alternative to passwords. If you are interested in digging deeper into FIDO, you can listen to the Identity, Unlocked podcast episode I recorded with Yubico's John Bradley on that very topic.

For the purposes of today's story, the important bit is that FIDO2, one of the sets of specifications the alliance produced, led to the widespread availability of phishing-resistant authentication features on modern devices. In short, that's achieved by describing how authenticators (physical keys, security hardware on devices, etc.) can talk to browsers and by defining a JavaScript API that websites can use to tap into those authenticators to perform public key cryptography authentication.

Clear as mud? In practice: by using the Javascript API defined in the WebAuthn specification, developers can leverage either hardware keys (e.g., YubiKeys) or secure hardware on the device (e.g., secure elements on your phone, TPMs on your laptop) gated by biometric sensors to authenticate users without using passwords. The two authenticator types are called roaming authenticators and platform authenticators, respectively.

Auth0 immediately saw the value in the initiative and adopted WebAuthn both as a second factor for administrators accessing our management dashboard and as a method developers can use to authenticate their users when protecting their web apps with Auth0.

Want to learn more about WebAuthn?Visit → webauthn.me

In 2020, I had the chance to present at the Authenticate conference the adoption figures we observed. The trends we identified reflect the industry at large: most of the adoption appears to be among professionals who need a high level of assurance when accessing the resources they manage, whereas consumer adoption isn't as steep.

There are many possible explanations for those results, but the consensus is clear: despite the giant progress in usability and widespread availability of hardware and software, those methods remain complex to use for end users. Hardware keys are an investment and a hassle, mostly reserved for admins and key knowledge workers. Platform authenticators are far more palatable, but they are tied to a single device: whereas in business scenarios that might be a coveted feature (e.g., admins like to know requests come from a managed device), for consumer scenarios that present challenges when migrating to new devices, using multiple devices and so on. Importantly, this also relegated WebAuthn to the role of the second authentication factor: the lack of a reliable recovery mechanism baked in the specs makes it necessary to provide at least another mechanism to access one's account. And that method, most often than not, ends up being… passwords.

Passkeys

Enter passkeys or, if you want to refer to them with their scientific name, multi-device FIDO credentials.

Passkeys are designed to eliminate the usability shortcomings of classic FIDO credentials or single-device credentials. They achieve this with a simple trick: they allow the FIDO credential to roam across multiple devices. This single-handedly solves both the recovery problem (credentials are now backed up, hence can survive the loss of their originating device) and the multiple enrollments problem (no need to repeat enrollment on each device).

Curious about how passkeys work? Try passkeys now →learnpasskeys.io

You can read more about it on the multi-device FIDO credentials landing page, on the whitepaper introducing the concept, or by listening to the Identity, Unlocked podcast episode I recorded with FIDO's exec director Andrew Shikiar and Microsoft's Tim Cappalli on that very topic - but the main thrust of the idea is really that simple.

Note: whereas multi-device FIDO credentials are the official FIDO denomination, vendors refer to the technology as "passkey" - I really like the term (pass-word, pass-key, get it? 😊), and it's significantly less typing; hence I'll use passkey for the rest of the article.

At this point, the sign-up and sign-in experiences remain somewhat vendor dependent, and the tasty bits (roaming) happen behind the scenes, but just to give you a taste: here's how a sign-up, sign-in, and a sign in on a different device look like on our early demo bits. You can find the full video later in the article.

Here's a test web application.

Let's say that we want to sign up; hence we click on "Open an account."

What you see there is a classic sign-up page, the same experience you'd see when signing up using a traditional username and password or a social provider. Let's fill the email address with our desired sign-up value and hit "Continue."

The prompt you see there is rendered by the identity provider. The page sensed that the client device is passkey capable; hence it offers the option to sign up by creating a new passkey. Let me stress this: the experience you see here is entirely under the control of the identity provider.

Let's choose "Continue with passkey."

Now, this dialog does come from the platform vendor, in this case, Apple (I am running the demo in Safari on a Mac mini with macOS Ventura and a Touch ID keyboard). The prompt is pretty clear. Let's touch the sensor and see what happens.

Behind the scenes, a new passkey for this identity provider is created. The device will take care of storing it and beginning the roaming process, while the identity provider will store the corresponding public key through the user sign-up process (more details in the next section) and start a session. Let's sign out and sign back in to observe what the normal login process looks like with passkey.

Now that the device has a passkey for this domain, as soon as I click in the username field, I am offered (via local dropdown/toaster) the chance to use it. All I need to do is to rest my finger on the Touch ID sensor, and we are in.

That is pretty cool in itself, but apart from the fact that we were able to enroll in biometrics without any extra recovery factor, not an entirely unfamiliar experience. Time for some magic, tho!

If we pick up an iPhone with iOS 16 beta, where I am signed in with the same iCloud user, and we use Safari to navigate to the same web app... upon signing in, we get the following screen.

Exactly as advertised! The passkey created on the Mac roamed to the iPhone and made it possible to sign in to the web app by Touch ID. Incredibly convenient… and phishing resistant.

Besides giving you a sense of how seamless passkey-based experiences can be, the flow demonstrated a key characteristic of passkey: at this point in time, passkeys are meant to roam within the boundaries of the vendor ecosystem they have been created in. In this scenario, everything hinged on my iCloud user. Passkeys roamed thru my Apple devices, similar to what happens with many other settings: keychain, contacts, photos, trusted wifi networks, app store purchases… and this is really one of the reasons for which we believe passkey can be successful where other attempts to dethrone passwords have failed, and the reason for the fancy Tao Te Ching quote at the beginning of the article.

Just like the ubiquitous availability of public key crypto-capable hardware, in the form of modern smartphones, making it possible for FIDO2 to introduce platform authenticators, today's widespread use of data services and roaming of settings within mobile and browser platforms is a key enabler for passkeys. The roaming machinery is already there, it is in widespread use, and vendors have been refining its security for years- just think of how dramatically the "old to new iPhone" settings transfer flow improved in the last few years. And as of today, passkeys are expected to roam only within their ecosystem. The passkey I created in my demo will only be available on my Apple devices where I use my iCloud account. More thoughts on that are in the Challenges section later in the article.

This doesn't mean that if I use devices from multiple vendors, I can't use passkeys, however. There is one last trick in passkey's sleeve I want to talk about today, and it's the ability to use passkey to perform a cross-devices authentication ceremony.

You can see the flow in action in the official FIDO demo here, but the keen observers among you might have already noticed hints of it in the screenshot of the first sign in the web app right after signing up. Along with the just-created passkey for victoria@somemail.com, you might have noticed an option labeled "Passkey from nearby devices…". I recommend you watch the video to get a sense of how the experience works, but in a nutshell:

• If you choose that option, the web page displays a QR code.
• If you have a device with you on which you have a passkey for the app you are trying to access, regardless of whether that device is from a different vendor than the requesting device, you can point its camera to the QR code and initiate an authentication ceremony.
• The two devices perform a Bluetooth handshake to ensure that they really are in the same geographical space (and, in so doing, prevent a whole sleuth of remote attacks) and agree on a remote server on the public internet to use as an exchange post.
• The device with the passkey is used to perform the passkey authentication ceremony; in case of a successful outcome, the user on the first device will find themselves signed in the web app. A bit as if the device with passkey were a wireless security key.
• At this point, it is recommended practice for the app to prompt the user about whether they want to create a new passkey on their current device. If they do so, they will now have a passkey for that app available to roam in the vendor ecosystem of the original device. For example: If you were accessing the web app from a Chromebook, and your authentication device was an iPhone, at the start of the flow, you only had a passkey for the web app on your Apple devices. At the end of the flow described here, you will still have a passkey for that website on your Apple devices AND a new passkey for that website in the Google ecosystem. Handy!

Are you sold on the experience yet? I bet many of you are, and displaying the classic bias for action that makes developers so effective at moving the world forward, you want to know how to make all this available to your users. Fair! Let's take a look.

Developing with Passkeys

Assuming for a moment that you are implementing authentication from scratch rather than relying on a service. From the implementation perspective, passkeys look just like platform authenticators that do not provide an attestation statement (more on that in the next section). That means that from the protocol perspective, if your web app already supports WebAuthn, as long as you don't verify the attestation, you technically already support passkeys. From the user experience perspective, however, that might not be entirely true.

• The prompts and language you have in your current enrollment pages likely refer to device-bound credentials (e.g., "Sign in faster from this device"), which is no longer the whole truth with passkey.
• Chances are that you are using platform authenticators to enable second authentication factors only, given that before passkey, you were directly responsible for account recovery (more on this in the next section).
• The way in which the local platform makes saved passkeys available relies on new native and browser APIs that are vendor specific at this point.

None of the changes above are particularly hard, especially if you already implemented WebAuthn, but you do need to do a bit of work to offer a good experience.

Of all the vendors who publicly committed to implementing multi-device credentials - Apple, Google, and Microsoft - Apple is probably the furthest ahead. They offer passkey support on both their macOS and iOS betas and devoted significant time at their latest developer event to explore the API they added in their OS and Safari to allow app and website developers to seamlessly integrate passkeys in their experiences. That's why we did all of our initial experimentations on Apple hardware, and if you want to dig into the details, that's probably your best option, too.

However, if you want to experiment with passkeys in your apps, you'll soon have a more direct, significantly simpler route. Auth0 lab, our research and development arm, is working on integrating passkey to the options Auth0 offers for handling authentication in applications. In practice, that means that if you integrate an app with Auth0, using classic protocols such as OpenID Connect, you'll be able to flip a literal switch in the authentication settings and enable passkey support on the authentication prompts used with your app. If you already have an app configured to use Auth0 for authentication, you'll be able to flip that switch and enable passkey authentication without touching your code at all.

If you want to see that flow in action and watch a video version of the screenshot sequence the preceding sections used to describe the main passkey flows, check out the demo below: it was featured during the Developer Days keynote in 2022.

This barely scratches the surface of what passkey scenarios we believe we can enable with easy, no-code affordances. However, this simple demo should be enough to get a sense of what can be achieved and our commitment to promoting the adoption of this new promising technology.

Challenges

After all this waxing lyrical about passkey, you'd think the industry found its holy grail, but alas, the full story has a bit more nuance.

If the starting point is passwords, passkeys are an obvious improvement. Their use of public key cryptography and FIDO authentication ceremony makes them pretty much unphishable, and that's an enormous leg up over shared secrets.

If the starting point is classic FIDO2 platform authenticators, however, passkeys do indeed drop some good security properties. Although it has some usability challenges, some administrators want credentials to be bound to one particular device- perhaps one that they control via MDM and are confident in its compliance with security policies. At the same time, opting out of passkeys and keeping using classic platform authenticators might not be trivial. Having implemented passkeys as platform authenticators makes it possible to support passkeys with existing WebAuthn implementations, but it also means that confusion is possible - in some cases, by design. For example, Apple has announced that once passkey is supported in released operating systems, they will no longer allow the creation of device-bound keys, e.g., the platform authenticators as we know them today - everything will be passkey (with the exclusion of roaming authenticators, e.g., hardware keys, which remain untouched). The thought that vital credentials of highly privileged users could be backed up to devices administrators have no knowledge or control over will keep many admins awake at night.

Other aspects aren't likely going to make administrators very happy. For example, as of today, passkeys require iCloud and sync to be on in order to function- a policy that might be currently disabled in devices meant for workplace workloads. Or the fact that a passkey can be simply shared via AirDrop to a nearby device.

Many of those decisions are vendor specific; hence they shouldn't be seen as absolutely inevitable. For example, it remains to be seen if Google and Microsoft will also consolidate all platform authenticators as passkeys. Furthermore, some new features in FIDO will help web apps to establish whether the incoming authentication operation used credentials that can roam ("backed up") and whether they have already been backed up. All those features will hopefully help to design policy enforcers that will assist administrators in retaining control of what they accept.

The other double-edged sword with passkey is the account recovery aspect. The fact that passkeys now roam within one vendor's set of synched devices, and access to them is gated to the corresponding account (as was the case with my iCloud account, my Mac, and my iPhone in the demo) means that access to the passkey collection is as secure as access to the account on which the roaming features hinge. Whereas a consumer application will likely be very happy to outsource that headache to Apple/Google/Microsoft, many administrators might not be comfortable with that situation. Once again, we will need to wait for all the vendors involved to release their passkey implementations to understand the true impact and what mitigations will be available.

Finally: some people are uncomfortable with the thought of a few providers, namely the operating systems and browsers vendors, controlling vital artifacts on the critical path for accessing… well, everything, if the move away from passwords were to fully succeed. There is not an easy answer to that. One might argue that we are already in that situation, and that is one of the things that is making something like passkey viable. I choose to be optimistic: I hope that if the technology does catch on, there will be ways to plug third-party providers and, in general, make the ecosystem more equitable and fair. Once again, these are very early days!

The Road Ahead

We believe that passkeys offer a viable alternative to passwords for consumer applications, and we are committed to promoting this much-needed industry shift by making it easy for you, developers, and builders to offer that experience to your users.

Passkeys do introduce new challenges, especially for the workforce and mission-critical solutions, apps relying on FIDO's platform authenticators as they are implemented today, and various other scenarios. Passwords do need to go, though: as an industry, we'll need to find ways to reap the advantages of this new technology while minimizing the drawbacks.

We are committed to doing our part, both by providing timely, state-of-the-art, developer-friendly features enabling passkeys - and by actively participating in the industry discussions shaping the future of this technology.

These are exciting times, full of potential and promise for everyone involved. Will you join us on this journey?