Understand Passkeys — with a Cup of Coffee

Grab your favourite brew and let's explore how passkeys work — from the cryptography behind them to a hands-on demo you can try right here.

☕ What are Passkeys?

Passkeys are a modern replacement for passwords based on the WebAuthn (Web Authentication) standard. Instead of memorising a secret string, your device creates a public/private key pair that is unique to you and the website. The private key never leaves your device — only a cryptographic proof is sent to the server.

Think of it like a coffee shop loyalty card that only your fingerprint can stamp — even if someone photocopies the card, they can't forge your stamp.

Passwords vs Passkeys

	Passwords	Passkeys
Storage	Server stores a hash of your secret	Server stores only your public key
Phishing	Can be typed into fake sites	Cryptographically bound to the real domain
Reuse	Users often reuse across sites	Unique key pair per site, automatically
Breach impact	Hashed passwords can be cracked	Public keys are useless to attackers
User effort	Must remember or use a manager	Biometric/PIN unlock — nothing to remember

🔑 How it works — the Cryptography

Passkeys use asymmetric (public-key) cryptography. During registration your authenticator (the device's secure enclave, a hardware key like YubiKey, or the OS credential manager) generates a key pair:

Private key — stays on your device, protected by biometrics or a PIN. Never sent anywhere. Like the secret recipe for your favourite espresso blend.
Public key — sent to the server and stored alongside your account. Like the menu board — everyone can see it, but it doesn't reveal the recipe.

During login, the server sends a random challenge. Your authenticator signs the challenge with your private key. The server verifies the signature using the stored public key. If it matches — you're in.

📝 Registration Flow

Like ordering your first cup — the barista (server) needs to get to know you:

Browser Server Authenticator | | | | 1. "I want to register" | | | ---- surname --------------> | | | | | | 2. Challenge + options | | | <---- challenge, rpId ------ | | | | | | 3. navigator.credentials.create(options) | | -----------------------------------------------------------> | | | Generates key pair | | | Signs challenge | | 4. Attestation response | | | <----------------------------------------------------------- | | | | | 5. Send attestation to server| | | ---- publicKey, signedData ->| | | | 6. Verify & store public key | | 7. "Registration complete!" | | | <---- OK ------------------- | |

🔒 Authentication Flow

Coming back for another cup — the barista recognises your order:

Browser Server Authenticator | | | | 1. "I want to log in" | | | ---- surname --------------> | | | | | | 2. Challenge + allowed creds | | | <---- challenge, credIds --- | | | | | | 3. navigator.credentials.get(options) | | -----------------------------------------------------------> | | | Finds matching key | | | Signs challenge | | 4. Assertion response | | | <----------------------------------------------------------- | | | | | 5. Send assertion to server | | | ---- signature, authData --> | | | | 6. Verify signature with | | | stored public key | | 7. "Welcome back!" | | | <---- OK ------------------- | |

☕

📚 Key Concepts

Relying Party (RP)

The website/server you are authenticating to. Identified by its domain (rpId). The authenticator binds the key pair to this domain, which prevents phishing — like how your loyalty card only works at one coffee chain.

Challenge

A random value generated by the server for each ceremony. Prevents replay attacks — a captured response cannot be reused because the challenge changes every time. Think of it as the daily special that changes each morning.

Credential ID

A unique identifier for each passkey. The server stores this so it can tell the authenticator which key to use during login — like the order number on your receipt.

Attestation (Registration)

The authenticator's response during registration. Contains the new public key, credential ID, and optionally proof of the authenticator model.

Assertion (Login)

The authenticator's response during login. Contains a signature over the challenge and some metadata, proving possession of the private key.

User Verification

The authenticator can require biometrics, PIN, or device unlock before using the key. This provides "something you are" or "something you know" on top of "something you have" (the device) — two factors in one sip.

☕

🎧 Interactive Demo — Try it!

Time to taste-test! Enter your surname below and register a passkey, then log in with it. All data is stored in server memory only — it resets when the server restarts, like a fresh pot of coffee each morning.

Your Surname

🔎 What just happened?

When you clicked Register:

The browser asked the server for a registration challenge and options (steps 1-2 in the diagram above).
Your operating system or browser popped up a prompt to create a passkey. Behind the scenes, a new key pair was generated inside a secure enclave.
The public key and signed attestation were sent back to the server, which verified and stored them.

When you clicked Login:

The server sent a fresh random challenge.
Your device found the matching private key, signed the challenge, and sent the signature back.
The server verified the signature against your stored public key. No password was ever transmitted.

🛡 Security Properties

Phishing-resistant: the credential is bound to the exact domain. An attacker on a different domain cannot trigger your passkey — like how your key only fits your front door.
No shared secrets: the server never sees your private key. Even if the database leaks, attackers get only public keys — useless without the private half.
Replay-proof: every ceremony uses a fresh random challenge. Old responses are useless, like yesterday's coffee grounds.
Multi-factor in one gesture: possession of the device + biometric/PIN = two factors in a single step.

Understand Passkeyswith a cup of coffee