WebAuthn and FIDO2, Explained Like You're a Human Being

There's a graveyard of acronyms in my browser history from the year I tried to ship passwordless login the wrong way. WebAuthn. FIDO2. CTAP. UAF, which thankfully you can forget about. For about a month I treated them as interchangeable magic words, mumbled them at problems, and got mysterious errors in return. The standards aren't actually hard — they're just badly named, and nobody draws you the map. So let me draw you the map I wish I'd had when I started building Paswad.

Strip away the jargon and this is a story about three things that have to agree with each other for you to log in without a password. That's it. Three roles, two ceremonies, and one good idea wearing a lot of name tags. Once you see how the pieces snap together, the acronyms stop being scary and start being almost boring, which in security is the highest possible compliment.

What these words actually mean

WebAuthn is the part your browser speaks. It's a web standard — a JavaScript API baked into Chrome, Safari, Firefox, Edge — that lets a website say "please create a passkey" or "please prove this user with their passkey." When a developer wires up passwordless login, WebAuthn is the doorway they're calling through. It's the public-facing half, the bit that touches the web page.

CTAP — Client to Authenticator Protocol — is the part nobody sees. It's how your browser or operating system talks to the actual authenticator: the secure chip in your laptop, or a USB security key, or your phone acting as a key over Bluetooth. WebAuthn handles the conversation between website and browser; CTAP handles the conversation between browser and the thing holding your private key. FIDO2 is just the umbrella term for the two of them working together. So FIDO2 = WebAuthn + CTAP, and the FIDO Alliance is the standards body that herds all of this. Congratulations, you now understand more than I did after my first month.

The three roles, and who's who

Every passkey login is a three-way handshake. Picture a slightly paranoid nightclub.

• The relying party is the website or app you're logging into — your bank, your email, the club itself. It's "relying" on someone else to vouch for you, hence the stiff name. It stores your public key and issues challenges, but it never holds a secret about you.
• The authenticator is the thing that actually holds your private key and does the signing. Could be the Secure Enclave in your phone, a TPM in your laptop, or a physical YubiKey on your lanyard. This is the bouncer who knows your face.
• The client — usually your browser, sometimes the OS — is the middleman that carries messages between the two and makes sure nobody's lying about which website is asking. Think of it as the host who walks you to the right room and checks the address on the door.

The reason this matters is that the client enforces something crucial: the request has to come from the real website. The browser checks the domain making the request and refuses to let your authenticator sign for an impostor. That single check is why passkeys laugh at phishing. A fake login page can copy every pixel, but it can't fake the domain the browser sees, and your authenticator simply won't produce a signature for the wrong address.

Two ceremonies: registration and authentication

The spec calls them "ceremonies," which I find a bit grand for what is essentially a polite exchange of math, but the word stuck so we'll use it. There are exactly two, and they mirror each other.

Registration: making the passkey

Registration happens once, when you first set up a passkey for a site. The relying party sends down a challenge and some info about itself. Your authenticator generates a brand-new key pair specifically for that site — a fresh private key it locks away in hardware, and a matching public key. It asks you to confirm with a fingerprint or face scan, then hands the public key back to the website along with a signed proof that the key is real. The site files away your public key next to your account. Notice what it never received: the private key, or your biometric. Those stay home.

Authentication: using the passkey

Authentication is what happens every time after. You arrive to log in, the relying party throws down a fresh random challenge, and your authenticator signs that challenge with the private key it made during registration — after checking your fingerprint or face to unlock it. The signature goes back, the site verifies it against the public key it stored, and the door opens. Same key pair, new challenge every time, no secret ever shared. Registration plants the seed; authentication is every harvest after.

Registration creates the key pair and hands over the public half. Authentication proves you still hold the private half. Everything else is plumbing.

Platform vs roaming authenticators

Authenticators come in two flavors, and the difference is just geography. A platform authenticator is built into the device you're using — Face ID on your iPhone, Windows Hello on your laptop, the fingerprint sensor on your Android. It's always there, it's convenient, and it's the default experience for most people. The passkey lives on that device (and often syncs to your other devices through an encrypted keychain).

A roaming authenticator is a separate gadget you carry between devices — a USB or NFC security key, or your phone vouching for your laptop over Bluetooth. These shine when you want one key that works everywhere, or when you're in a high-security setting where a physical, unsyncable token is the point. I keep a hardware key in a drawer the way some people keep a fire extinguisher: I almost never reach for it, and I'm extremely glad it's there. Most users will happily live on platform authenticators forever, and that's fine. The standard supports both because different people have different threat models, and pretending otherwise is how you build security nobody uses.

Why an open standard, and why the big three actually agree

Here's the part that still slightly astonishes me. Apple, Google, and Microsoft agree on almost nothing. They'd compete over the color of the sky if there were money in it. Yet all three sit on the FIDO Alliance and ship the exact same passkey standard, so a passkey you make on an iPhone works in Chrome on a Windows machine. That cross-vendor truce is not charity — it's the recognition that passwords were a shared disaster bleaking everyone's users, and a fragmented fix would've been worse than no fix.

Because it's an open standard, no single company owns your login. There's no proprietary "Sign in with MegaCorp" button quietly turning your identity into someone's data product. The spec is public, the implementations are interoperable, and anyone — a tiny startup, a sprawling bank, me — can build on it without asking permission or paying a toll. That openness is the reason I bet a company on it. I didn't want to build on quicksand owned by a giant who could change the rules on a Tuesday. WebAuthn is boring, public infrastructure, and boring public infrastructure is the only kind worth building a foundation on.

Frequently asked questions

What's the difference between WebAuthn and FIDO2?

WebAuthn is the browser-facing API that websites call to register and verify passkeys. FIDO2 is the broader standard that bundles WebAuthn together with CTAP, the protocol browsers use to talk to authenticators. In short: WebAuthn is one piece, FIDO2 is the whole kit.

What is a relying party?

It's the website or app you're logging into — the party "relying" on a passkey to confirm who you are. It stores your public key and issues the random challenges you sign, but it never holds any secret that could be stolen in a breach.

Do I need a separate hardware key to use passkeys?

No. Most people use a platform authenticator built into their phone or laptop, like Face ID or Windows Hello. A separate roaming hardware key is optional and mainly useful for high-security setups or as a portable backup that works across many devices.

Are passkeys really supported everywhere?

Support is broad and growing fast. Because Apple, Google, and Microsoft all back the same FIDO2 standard, passkeys work across major browsers and operating systems, and a passkey made on one platform can typically be used on another. Coverage isn't literally universal yet, but the major ecosystems are already on board.

So there's your map. Three roles, two ceremonies, one open standard wearing too many name tags. The acronyms were never the hard part — the hard part was that nobody bothered to translate them. Now that someone has, you can go back to ignoring them entirely, which honestly is the dream. Good security should be something you stop thinking about, and FIDO2 is finally boring enough to forget.