Auth0 passkeys
Adapting a new open authentication standard into Auth0’s identity platform, so any customer could offer passkeys to their users without reading the specification.
A new login standard, and a platform built around passwords
Passkeys are a phishing-resistant, passwordless alternative to passwords, built on an open standard from the FIDO Alliance. Apple and Google had shipped support in their browsers and operating systems, and the industry was starting to move toward them. Auth0 wanted to offer passkeys to its customers quickly, as a flagship feature.
Auth0 is identity as a service. Its customers configure Auth0 to handle sign-up, login, and recovery for their own users instead of building login themselves. So passkeys had to work twice: for the developers and admins setting them up in the Auth0 dashboard, and for end users, most of whom had never heard of a passkey and would meet one for the first time in someone else’s app.
The specification described how passkeys work, not how a platform should expose them. Auth0’s login had been built around passwords and came in many configurations: different login experiences, custom login pages, customers’ own databases, and usernames as identifiers. Several of those couldn’t support passkeys at launch. I designed passkeys at Auth0 from the ground up, from the end-user sign-up, login, and recovery flows to the dashboard where customers configure them.
Deciding how much of the specification customers should see
Evaluating new gaps in authentication methods
I started by mapping Auth0’s existing sign-up and login flows to see where passkeys would change them, then worked through the FIDO Alliance’s technical specification and UX guidance alongside B2B and B2C products that already supported passkeys. That showed which configuration patterns worked in practice, so I could generalize them for identity as a service instead of inventing new ones. I reviewed progress every week with senior identity architects, including one who had contributed to the specification.
Turn launch limits into a readiness check
At launch, passkeys needed several temporary requirements to function correctly. Customers needed Auth0’s New Universal Login and an identifier-first flow, and couldn’t use their own database unless its users were being imported. Rather than let customers discover that through a failed login, the passkey settings open with a list of prerequisites, each showing its status and linking to the setting that needs to change. Once passkeys were on, the related settings elsewhere in the dashboard warned admins before they changed something passkeys depended on.
Let end users move to passkeys at their own pace
Passwords stayed available alongside passkeys, and existing users weren’t forced to switch. After a successful password login, users could be offered a passkey, or they could choose not to be asked again for 30 days. This was designed so that our customers could nudge users to migrate, but they also had the option to turn this progressive enrollment on or off, and choose whether their users start a passkey login from a button, from browser autofill, or both.
Designing for people meeting passkeys for the first time
Our internal market and user research showed end users were unfamiliar with passkeys, skeptical about using them for sensitive accounts, and cared most about convenience. Enrolling in passkeys was a surprise to users in the flow, so we led with only facts about what it was: passwordless login that was faster to sign in with on their device, phishing-resistant to secure their personal data, and optional so they could continue without using a passkey.
I designed the sign-up, login, and recovery flows across the cases the specification allows: a passkey on the current device, one on a phone scanned from a QR code, and passkeys synced across a person’s devices.
Recovery had three paths. Synced passkeys point people to their provider, like Apple or Google. Passkeys on a single device go through regular recovery with the option to create a new one. Where there’s no fallback, customers can add their own support contact.
For admins, each user’s profile lists their passkeys similar to their pre-existing MFA methods, labelled as synced or tied to a single device. To avoid leaving users at a dead end, I designed a warning that appears before an admin revokes someone’s last passkey. I also updated the component library for Auth0’s login framework so other designers working on authentication could build from the same patterns. It was the first time in years that someone had gone through the code and error states, and I was able to document the entire default flow for others to leverage in their process, using composable design components.
Adoption well past a deliberately cautious target
Passkeys launched in 2023. Because of the launch limits and how new the technology was, the team set its adoption target conservatively, and adoption reached more than 360% of it in the first quarter. Customers on free and paid plans turned it on within the first weeks, and more than 1,000 customers went on to use passkeys in their authentication flows, with over 100,000 passkeys created over the first few quarters of 2024.
The release influenced deal retention totalling more than $15M in ARR, and Auth0 used it in presentations to industry analysts, including briefings for Gartner’s Magic Quadrant. Our own sales teams set it up on their tenants to demo to prospects, and early customers reported the documentation, launch materials, and user experience made setup straightforward.
The part I’d carry into any new standard is the translation work. A specification describes what’s possible, but a platform has to decide what each customer needs to see and what can stay out of their way. Most of my work on passkeys was making those decisions, and ensuring a developer could turn on a new standard without having to worry about reading it.