Passkeys · FIDO2 / WebAuthn

What are passkeys?

A passkey is a key you sign in with instead of a password. Built on the FIDO2 / WebAuthn standards from the FIDO Alliance and the W3C, passkeys let users sign in with a fingerprint, a face, or a PIN. There is nothing to remember and nothing to type.

01

In one sentence

A passkey is a public-key cryptography key pair created inside the user's device.

When a user registers a passkey, the device (a phone, a PC, or a security key) generates a private key and a public key. The private key never leaves the device; the service stores only the public key. At every sign-in, the device signs a one-time challenge from the service with the private key, and the service verifies the signature with the public key.

From the user's point of view it is just a fingerprint, a glance at the camera, or a PIN. The whole act of remembering, typing and reusing passwords disappears.

The private key never leaves the deviceIt does not exist on the server or on the network.
One key pair per siteA passkey is bound to the domain (origin) it was registered for and cannot be used elsewhere.
User verification happens on the deviceBiometric data never leaves the device and is never sent to the service.

02

How it works

Two ceremonies: registration and authentication.

Passkeys involve two flows: registration and authentication. Both share the same structure: the service (the Relying Party, or RP) issues a challenge, the device responds after verifying the user, and the service verifies the response. The steps below use the actors involved when Quado is the FIDO server.

ARegistration: creating a passkey

  1. Your system → Quado A signed-in user chooses "Add a passkey". Your system calls Quado's registration API, and Quado returns registration options including a one-time challenge and the conditions for acceptable authenticators.
  2. Your system → Browser / App The options are passed to the browser, which calls the WebAuthn API (navigator.credentials.create()).
  3. Browser / App → Authenticator The authenticator (Touch ID, Face ID, Windows Hello, a security key, and so on) verifies the user and generates a brand-new key pair for this service. The private key is stored inside the authenticator.
  4. Authenticator → Browser → Your system → Quado The public key and attestation data describing the authenticator are returned to the server. Quado verifies the challenge, origin, signature and attestation, then stores the public key against the user's identifier.

Result: the private key is on the device, the public key is in Quado. The passkey is ready to use.

BAuthentication: signing in with a passkey

  1. Your system → Quado The user chooses "Sign in with a passkey". Your system calls Quado's authentication API and receives authentication options including a one-time challenge.
  2. Your system → Browser / App The browser calls the WebAuthn API (navigator.credentials.get()).
  3. Browser / App → Authenticator The authenticator verifies the user (biometrics or PIN) and signs the challenge with this service's private key. The private key itself never leaves.
  4. Authenticator → Browser → Your system → Quado The signature is returned to the server. Quado verifies it with the registered public key and checks the challenge, origin and signature counter. Your system then establishes the session.

Result: only the challenge and the signature ever cross the network. They cannot be replayed, and a fake site cannot obtain a valid signature.

See the architecture section on the top page for how your system and Quado fit together.

03

Passkeys vs passwords

PasswordsPasskeys
What the server holdsA password (hash). If leaked, it is a target for brute force.Only a public key. Useless for impersonation even if leaked.
PhishingTyped into a fake site, it is stolen.Keys are bound to the origin, so a fake site cannot obtain a valid signature.
ReuseOne password across many services turns one breach into many.A separate key pair per service. Reuse is structurally impossible.
User effortRemember, type, rotate, reset when forgotten.Biometrics or a PIN. Nothing to remember.
Operating costPassword-reset support, complexity policies.Resets all but disappear; instead, plan recovery for lost devices.
Multi-factorAchieved by adding SMS or one-time codes."Something you have" (the device) and "something you are / know" (biometrics / PIN) in a single step.

04

Types of passkeys

Synced passkeys

Synced passkeys

The private key is synchronized across a user's devices through iCloud Keychain, Google Password Manager or a third-party password manager. Switching phones or adding devices is easy, which suits consumer services.

Device-bound passkeys

Device-bound passkeys

The private key never leaves a single device: a security key, a PC's TPM, or a phone's secure enclave. Because you know exactly where the key lives, this suits finance, enterprise systems and other high-assurance use cases.

The standards also define cross-device authentication: signing in on a PC browser with a passkey stored on your phone, by scanning a QR code and confirming proximity over Bluetooth. This lets users sign in securely even from a device that holds no passkey.

Which types to accept is controlled by the RP through the registration options. Quado can apply acceptance policies based on the attestation returned by the authenticator and the attributes captured at registration.

05

Glossary

FIDO
Fast IDentity Online. The FIDO Alliance, the industry body that standardizes authentication without passwords, and its family of specifications.
FIDO2
The FIDO Alliance's current generation of specifications, made up of WebAuthn for browsers and CTAP between the client and the authenticator.
WebAuthn
Web Authentication, the browser API standardized by the W3C. navigator.credentials.create() / get() invoke the authenticator. Supported by all major browsers.
CTAP
Client to Authenticator Protocol. How a PC or phone talks to an external authenticator (a security key or a phone) over USB, NFC or Bluetooth.
Passkey
The user-facing name for a FIDO2 / WebAuthn credential, adopted as a common term by Apple, Google and Microsoft from 2022. Technically it usually refers to a discoverable credential.
Authenticator
The hardware or software that generates and stores key pairs, verifies the user and signs. Platform authenticators are built into the device (Touch ID, Windows Hello); roaming authenticators are external (security keys).
RP (Relying Party)
The service that authenticates users with passkeys; "your system" on this page. The RP ID is a domain name, and passkeys are bound to it.
UAF / U2F
The specifications that preceded FIDO2: UAF for passwordless authentication in mobile apps, U2F for two-factor authentication with security keys. Quado supports both in addition to FIDO2.

06

What you need to deploy passkeys

Supporting passkeys is more than calling a browser API. The service needs a server that handles the FIDO protocol correctly.

  1. 1

    Front end: calling WebAuthn

    The part of your sign-in and registration screens that calls the WebAuthn API and talks to the authenticator. Every major browser and OS provides it.

  2. 2

    Back end: a FIDO server

    Issuing and tracking challenges, verifying attestations and signatures, storing public keys and signature counters, enforcing authenticator policies. This is the hardest part to build and maintain, and it is what Quado does.

  3. 3

    Design: journeys and recovery

    Coexistence with existing ID/password sign-in, registering multiple devices, recovery when a device is lost, and which authenticators to accept. More than the technology, this decides whether a rollout succeeds.

Quado is a FIDO server package certified by the FIDO Alliance as a Universal Server (FIDO2 / UAF / U2F) that runs in your on-premises environment or inside your VPC. Your existing system adds passkeys by calling the registration and authentication REST APIs.

Talk to us about deployment See Quado's specs

07

Frequently asked questions

If I lose my device, am I locked out?

With synced passkeys, you can keep signing in from another device on the same account. With device-bound passkeys, register more than one device (or a backup security key) in advance, or keep a recovery path through an existing authentication method. Deciding on recovery during service design is essential.

Is my biometric data sent to the server?

No. Fingerprint or face matching happens entirely on the device; the server only receives a signature that carries the result of user verification. Quado itself stores only the user's identifier and public key.

Which browsers and operating systems support passkeys?

iOS / iPadOS / macOS (Safari and others), Android (Chrome and others) and Windows (Edge, Chrome, Firefox) all support WebAuthn. The scope of synced passkeys depends on the OS and password manager, so the design should match your users' environments.

Can passkeys coexist with our existing password sign-in?

Yes. A common approach is to let users who signed in with a password register a passkey, then prefer the passkey from the next sign-in on. Because Quado works through a REST API, it can be added alongside your existing authentication.

Are synced passkeys secure?

Private keys are end-to-end encrypted during sync, and from the RP's point of view the signature verification is unchanged. Because the key depends on a cloud account, higher-assurance use cases may choose to accept only device-bound passkeys, which is a policy the RP can enforce.

Next step

Deploy passkeys
with Quado.

Contact us About Quado