Going passwordless with passkeys
Own your UX
Customize our pre-built UI
Simplify your user experience
Implement with confidence
Invest in the future of auth
How it works
The ultimate password replacement
Signup and login – tailored to your product
From breach-resistant passwords to the latest passwordless solutions, Stytch’s consumer auth API has everything you need to build the ideal auth flow and UX for your customers.
What is a passkey?
A passkey, created by the FIDO alliance, uses WebAuthn technology to combine public key cryptography with native biometrics. Unlike WebAuthn, however, a passkey syncs to the cloud and works across devices. Passkeys eliminate the need to save or memorize a password, regardless of what device a user is on.
A passkey, in fact, is a complete replacement for a password. Its familiar user experience paired with its increased security has generated lots of hype as a more secure and more user-friendly password alternative.
We're all aware of the password problem – passwords are both easily compromised and frustrating for users. The passkey is positioned to become the new, default authentication method.
Because it combines the security of WebAuthn with a form of biometric authentication, a passkey offers all the benefits of passwordless authentication, namely better security and user experience, without major drawbacks like too many steps or unfamiliar or new interfaces.
How does a passkey work?
Passkey technology relies on public key cryptography. Instead of a username and password, all users have a public key and private key associated with them (aka a key pair). When a user signs up for an application with a passkey, their device generates two keys – a private and public key pair – for that particular application.
The passkey then manages user authentication by harnessing the interaction of the public key (that everyone can access) with the private key (that only the user can access), and then syncing it to the cloud so the passkey can be used across devices.
- Stored server-side
- Does not include secrets, raw data, or biometric data – not a hacking target
- Stored locally in a device or password manager
- Protected by biometric data (FaceID/TouchID)
- Synced to the cloud (e.g., iCloud, Google, Microsoft), enabling cross device authentication
When the user signs in next, the application’s server will submit a challenge encrypted with the public key that can only be decrypted with the private key. Once the user verifies their identity via biometrics, the private key will solve the challenge.
The device then sends this signed response back server-side where the public key will verify the response and admit the user to your application.
Once this is confirmed, the user has been authenticated successfully and is logged in via passkey.
Is a passkey more secure than a password?
In a word, yes. Passwords are prone to a variety of cyberattacks.
Credential stuffing attacks, for example, stem from weak passwords re-used across multiple platforms. When one site gets hacked, a bad actor will take those compromised passwords and use them on that user's other, unrelated accounts.
Passwords are also a vehicle for phishing attacks. In a phishing attack, a bad actor deceives a good user into handing over their password. This bad actor can use this password to sign in to this user's account (and even proceed with another type of brute-force cyberattack).
Unlike passwords, a passkey excludes user judgment. Not only does the "behind-the-scenes" nature of the cryptographic keys create a better user experience, it also means that your users are no longer in charge of choosing, remembering, and protecting one of the more exploitable vectors for account takeover – namely login credentials.
Why do I keep seeing the term "FIDO"?
Will a passkey work across all user devices?
In theory, yes. Any passkey by design should sync with the cloud and work across all your devices.
For example, if you create a passkey on your iPhone for Netflix, that passkey will sync to iCloud so you can also sign in to Netflix on your Macbook using a passkey.
It's important to note that although a passkey functions across device and operating system, each passkey is specific to the application it was created for.
Using this same example, a Netflix passkey will not let you sign in to Verizon, but if you create a separate passkey for Verizon, that will also work across devices and operating systems with no additional lift to the user (other than creating the Verizon passkey).
In reality, however, a passkey’s syncing ability today still depends on the ecosystem and platform of its user. This means that although passkeys, in principle, should work seamlessly across devices, the current state of support leaves some gaps (see the FAQ below).
Which factors affect a passkey’s functionality?
Two of the biggest factors that affect passkey functionality are the end user’s platform and the decisions developers make in the technical configuration of the passkey.
The end user’s platform – which consists of a combination of operating system, cloud ecosystem, browser, and device type – can affect both syncing and security. For example, cloud syncing today is only supported in a select few OS/browser combinations (see our passkeys blog for more info on this).
Additionally, if the user’s device does not support biometrics, their PIN-based user verification security will be worse than someone’s using a thumbprint or face.
Second, the technical configuration that developers choose can have huge effects on a passkey’s user experience and security. These technical considerations include the type of authenticator (built-in biometrics vs. YubiKey), resident key (whether the authenticator stores metadata to make the passkey discoverable client-side), and user verification method (what kind of verification the user must complete before the authenticator generates/fills in a passkey).
Why doesn't everyone offer passkey support?
The passkey is new technology, and as such is not yet available for all users in every ecosystem. Although tech giants like Apple encourage passkey adoption, widespread adoption is more like a dimmer switch than an on-off switch.
A couple things are affecting this, on both the user’s end and on the application’s side.
For one, users must run a later iOS operating system on their devices. Given how long it will take the general public to update their systems, along with the fact that 14% of users prefer using passwords, all signs point to a slow rollout.
On the application side, there are also updates required to support passkeys. Although no different from making other changes to your authentication strategy, developers still need to think about how a passkey deployment could impact their user model and relevant account recovery flows.