Passkeys Explained: How Passwordless Authentication Works

Passkeys have been around for a while now. You have probably seen them on larger websites such as GitHub and Google, where you can sign in without typing a password at all.

And every time I used them, I had basically the same thought: why don't more normal websites use this?

I wanted passkeys on my own website and products for a pretty simple reason: the experience is just better. You don't have to remember a password, open a password manager, copy anything, or wait for a verification code. You choose your passkey, confirm with your fingerprint, face, device PIN, or another authenticator, and you're in.

It feels almost suspiciously easy for something that is also, when implemented correctly, significantly more resistant to common attacks such as phishing and credential stuffing than traditional password-based authentication.

But once I started looking into actually implementing passkeys, I realized there is quite a bit happening underneath that simple fingerprint prompt. There is WebAuthn, FIDO2, public-key cryptography, relying parties, challenges, authenticators, credential IDs, discoverable credentials, browser APIs, and a few important decisions your backend needs to get right.

So this article is the conceptual part. We are going to look at what passkeys actually are, how they work, which standards are involved, what the browser and authenticator are really doing, what your frontend and backend are responsible for, and what happens in real-world situations such as losing your phone or signing in on another computer.

In a follow-up article, I will move from the theory to the actual implementation and build passkey authentication with Vue and Nuxt.

Let's get into it.

What are passkeys?

The easiest way to think about a passkey is as a replacement for a password that uses the security already built into your device.

Instead of typing a secret string that both you and the server need to somehow protect, you authenticate using something such as a fingerprint, face scan, device PIN, password manager, or hardware security key.

Underneath that much nicer user experience, passkeys are built on the Web Authentication API, usually called WebAuthn, and public-key cryptography.

If you want a more developer-friendly introduction than the raw W3C specification, the MDN Web Authentication API guide is also a very good reference.

When you create a passkey, an authenticator creates a cryptographic key pair:

• The private key is controlled by the authenticator or passkey provider and is not sent to your application during registration or authentication.
• The public key is returned to your application and stored on your server.

This distinction is the entire foundation of how passkeys work.

With passwords, the user and the server are ultimately dealing with the same secret. Ideally the server stores only a strong hash of the password, but the user still has to know or possess the original secret and send proof of it during login.

Passkeys change that model completely.

Your server does not know the secret used to authenticate. It only knows a public key that can verify signatures created by the corresponding private key.

If someone steals the public key from your database, they cannot use it to generate valid signatures. It is designed to be public.

This is one of the reasons a database containing passkey credentials is fundamentally different from a database containing password hashes.

The browser, authenticator, and server are different parts of the system

This is where passkeys became much clearer to me.

When you click something like Create a passkey, there are actually several different actors involved:

• Your application frontend, which starts the process.
• Your backend, which generates challenges and verifies the final response.
• The browser, which implements the WebAuthn API and enforces rules around origins and relying parties.
• The authenticator, which holds or controls the private key and performs cryptographic operations.
• The user, who authorizes the authenticator through a fingerprint, face scan, device PIN, hardware key, or another verification mechanism.

The browser and authenticator are related, but they are not the same thing.

The browser is basically the bridge between your website and the authenticator.

Your JavaScript asks the browser to create or use a credential through WebAuthn. The browser checks whether the request makes sense for the current website, communicates with an appropriate authenticator, gets the result back, and returns a WebAuthn response to your frontend.

When the authenticator is external, such as a hardware security key or another device, communication can happen through the Client to Authenticator Protocol, or CTAP. CTAP is the other major piece of FIDO2 alongside WebAuthn.

The authenticator is the component that actually controls the credential.

Depending on the device and setup, that authenticator might be:

• Windows Hello on a Windows computer.
• Touch ID or Face ID backed by Apple's credential system.
• An Android device using the platform's credential manager.
• A password manager capable of storing and synchronizing passkeys.
• A physical FIDO2 security key.
• A phone being used to authenticate a login on another computer.

So when people say, "the private key stays on the device," that is useful as a simplified explanation, but the reality is slightly more nuanced.

The important security property is that your website never receives the private key.

The authenticator or passkey provider controls it and exposes only specific operations such as "create a credential" and "sign this authentication request."

Your fingerprint is not your passkey

This is another distinction worth making because the user experience can make it seem like your fingerprint itself is being sent to the website.

It is not.

Your fingerprint, face scan, or device PIN usually exists to unlock or authorize the authenticator.

For example, imagine that your laptop contains a passkey for example.com. When you sign in, the website asks the browser to authenticate. The browser asks the authenticator to use the relevant credential.

The authenticator may then say: "Before I use this private key, prove that the actual device user is present."

Windows Hello might ask for your fingerprint. An iPhone might ask for Face ID. A security key might require you to physically touch it.

Once that local check succeeds, the authenticator is allowed to use the private key to produce a cryptographic signature.

The website receives the signature.

It does not receive your fingerprint image, Face ID data, Windows PIN, or other biometric information.

That verification remains local to the authenticator and operating system.

What exactly is stored inside a passkey?

A passkey is not just "a private key with a website name attached to it."

Conceptually, a credential is associated with several pieces of information that allow the browser, authenticator, and server to identify and use it correctly.

The exact internal representation depends on the authenticator, but from the application's point of view, some of the most important pieces are:

• Credential ID — a unique identifier for this specific credential.
• Private key — controlled by the authenticator and used to sign authentication data.
• Public key — stored by your server and used to verify those signatures.
• Relying Party ID — the website or domain scope the credential belongs to.
• User handle — an application-defined stable identifier that can associate the credential with a user.
• Discoverability information — for credentials that can be presented before the user enters an email or username.
• Authenticator-specific metadata — depending on the implementation and platform.

Your server does not need to understand how the authenticator internally stores the private key.

That is deliberately abstracted away.

Your application mostly cares about the credential ID, public key, user relationship, and the information required to verify future authentication responses.

What the server normally stores for a passkey

When a passkey is registered successfully, you normally create a record in your own database representing that credential.

A simplified database model might contain values such as:

• User ID — which account owns the passkey.
• Credential ID — the identifier returned by WebAuthn.
• Public key — used to verify future signatures.
• Signature counter — when provided and relevant for the authenticator.
• Transport information — hints about how the authenticator can be reached.
• Device or credential name — often something you add yourself for the user's convenience.
• Created date — useful for account management and security history.
• Last-used date — useful for displaying credentials and security monitoring.
• Backup or authenticator information — depending on what your WebAuthn library exposes and what you actually need.

Some of this information comes directly from WebAuthn. Some of it is metadata your application adds on top.

For example, WebAuthn does not magically know that you want to show the user a settings page saying:

MacBook Pro — added August 28 — last used two hours ago.

You build that product layer yourself.

You might ask the user to name a passkey when they create it, or automatically give it a generic label and allow them to rename it later.

That metadata is not part of the cryptographic secret. It simply makes credential management understandable to humans.

Credential IDs are important

The credential ID deserves more attention because it appears throughout a WebAuthn implementation.

Imagine a user has three passkeys registered:

• One on their laptop.
• One in a password manager.
• One on a physical security key.

All three belong to the same user, but each is a separate credential with its own credential ID and key material.

When an authentication response comes back, the credential ID tells your backend which stored public key should be used to verify the signature.

Your server can effectively say:

"This response says it came from credential ABC123. Let me find credential ABC123, get its public key, and verify the signature."

If the signature verifies and the rest of the WebAuthn checks pass, the server can then look at the owner of that credential and know which user is signing in.

This is also why users can have multiple passkeys attached to one account without your application becoming confused about which one was used.

What is an authenticator?

The word authenticator sounds more complicated than it really is.

An authenticator is basically the trusted component responsible for creating and using WebAuthn credentials.

It can usually perform operations like:

• Create a new credential and key pair.
• Store or control access to that credential.
• Ask the user for verification when required.
• Sign authentication data with the credential's private key.
• Return the credential ID and signed response to the browser.

Authenticators are often divided into two broad categories.

Platform authenticators

A platform authenticator is integrated into the device you are already using.

Windows Hello is a good example.

You are on your laptop, you create a passkey, and later you authenticate using the laptop's fingerprint reader, face recognition, or PIN.

The user does not have to plug anything in.

Roaming authenticators

A roaming authenticator is separate from the device running the browser.

A physical security key is the classic example.

You might create a credential on a USB or NFC security key and then use that key across multiple computers.

Modern passkey ecosystems blur these categories a little because phones can also act as authenticators for nearby computers, and passkey providers may synchronize credentials across multiple devices.

But the mental model remains useful: the authenticator is the thing that controls the credential and performs the cryptographic operation.

What does the browser actually do?

The browser is doing much more than displaying a nice fingerprint popup.

When your frontend calls WebAuthn, the browser participates in enforcing some of the most important security boundaries in the protocol.

It knows which origin your JavaScript is running on.

It knows which relying party the website is requesting a credential for.

It communicates with available authenticators through the operating system and supported authenticator protocols.

It also packages WebAuthn data in a standardized structure that your backend can later verify.

This is why WebAuthn is fundamentally different from building a custom JavaScript authentication protocol yourself.

Your application cannot simply tell the authenticator:

"Pretend I am google.com and give me Google's credential."

The browser and authenticator participate in checking whether the relying-party request matches the current web context.

How passkey registration works in detail

There are two major WebAuthn ceremonies: registration and authentication.

Registration is where a new credential is created.

The process starts on the backend, not inside the authenticator.

Your backend generates a random challenge and creates a set of registration options. Those options describe things such as:

• The challenge.
• The relying party.
• The user identifier.
• The user's display information.
• Whether user verification is required.
• Whether you prefer a discoverable credential.
• Credentials that should be excluded because they already exist.
• Cryptographic algorithms the server accepts.

Your frontend receives those options and passes them to the browser.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant S as Application server
    participant A as Authenticator
    participant D as Database

    U->>B: Choose "Create a passkey"
    B->>S: POST /passkeys/register/options
    S->>S: Generate random challenge
    S->>S: Set RP ID, origin, user ID, and user verification policy
    S-->>B: Creation options and challenge cookie
    B->>A: navigator.credentials.create(options)
    U->>A: Unlock with fingerprint, face, PIN, or security key
    A->>A: Generate key pair and retain private key
    A-->>B: Return credential ID and public key
    B->>S: POST /passkeys/register/verify(response)
    S->>S: Read and consume challenge
    S->>S: Verify origin, RP ID, challenge, and user verification
    S->>D: Store credential ID, public key, counter, and metadata
    S-->>B: Registration succeeded

Once the browser receives those options, it invokes an authenticator.

The authenticator may ask the user for local verification.

Then it creates the credential and generates its key pair.

The private key remains under the authenticator's control.

The browser receives a registration response containing information that allows your server to verify what just happened.

This registration response is commonly referred to as an attestation response.

The server then verifies several things before trusting it.

Among them:

• Was this response created for the challenge we just issued?
• Has that challenge already been used?
• Does the origin match the website we expect?
• Does the relying-party information match?
• Was user verification performed if we required it?
• Can the credential data be parsed and cryptographically validated?

Only after those checks succeed do you save the credential.

This is why the registration response should never simply be accepted because "the browser sent it."

The browser is part of the protocol, but your backend still treats anything arriving over HTTP as untrusted input.

Attestation does not mean your server receives the private key

The name attestation can make the registration response sound as if the authenticator is handing your backend everything about itself.

It is not.

The important result for your application is that you receive the newly created credential's public information and enough signed or structured data to validate the registration ceremony.

The private key does not come along for the ride.

Your WebAuthn library typically parses the registration response and gives you the pieces you actually need to store, such as the credential ID, public key, and counter.

Depending on your authenticator policy and implementation, attestation can contain additional information about the authenticator. Many consumer-facing applications do not need to build their product around identifying the exact hardware model of every authenticator.

In most normal web applications, your real goal is simpler:

Did a valid authenticator create a valid credential for the correct user and the correct website in response to the challenge I generated?

How passkey authentication works

Authentication is the second ceremony.

This time, no new key pair needs to be generated.

Your server wants the authenticator to prove that it controls the private key corresponding to one of the public keys you already have stored.

Again, the backend begins by generating a fresh random challenge.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant S as Application server
    participant A as Authenticator
    participant D as Database

    U->>B: Choose "Sign in with a passkey"
    B->>S: POST /passkeys/authenticate/options
    S->>S: Generate fresh challenge
    S-->>B: Request options + challenge cookie
    B->>A: navigator.credentials.get(options)
    U->>A: Unlock authenticator
    A->>A: Sign challenge + origin + RP data with private key
    A-->>B: Assertion: credential ID + signature
    B->>S: POST /passkeys/authenticate/verify(assertion)
    S->>D: Find credential by credential ID
    S->>S: Verify signature with stored public key
    S->>S: Check challenge, origin, RP ID, user verification, counter
    S->>S: Create authenticated session
    S-->>B: Session cookies / tokens

The browser asks the authenticator for a matching credential.

The authenticator may ask the user to verify themselves locally.

Once authorized, the authenticator signs data related to the authentication ceremony using the private key.

The result sent back to the server is generally called an assertion.

The assertion includes the credential ID, which allows your backend to identify the correct stored credential.

Your backend finds that database record, loads its public key, and asks the WebAuthn verification library to verify the signature and the surrounding protocol data.

If everything checks out, you now know that the party producing the response controls the private key corresponding to the public key you stored during registration.

Notice what did not happen.

• The private key was never sent to your backend.
• The user did not send a reusable password.
• The fingerprint was never sent to your backend.
• The server did not decrypt anything using the public key.

The server simply verified a signature.

Why the challenge matters

The challenge is one of those details that can look like boring protocol plumbing until you realize what attack it prevents.

Suppose an attacker somehow records a valid authentication response from yesterday.

Without a fresh challenge, they could potentially send that exact response to your server again.

A challenge prevents that.

Your server generates a random value specifically for the current authentication attempt. The signed response is tied to that value.

If someone replays an old response, it contains an old challenge and verification fails.

This is why challenges should be:

• Cryptographically random.
• Short-lived.
• Associated with the correct ceremony or session.
• Consumed after successful or attempted use according to your design.

You should not generate a permanent "challenge" once for every user and keep reusing it forever.

Why passkeys are resistant to phishing

This is one of the parts I found particularly interesting.

A WebAuthn credential is scoped to something called a relying party ID, or RP ID, which is normally related to the website's domain.

A passkey created for example.com cannot simply be used by evil-example.com.

The browser and authenticator participate in enforcing this relationship.

So imagine an attacker builds a perfect clone of your login screen.

With a traditional password, the user can accidentally type their real password into the fake website. The attacker now possesses something reusable.

With WebAuthn, the fake website does not get to simply request a valid credential for the real domain.

The credential is tied to the relying party it was created for.

There is no equivalent of "just type your passkey into this phishing form."

This is one of the strongest conceptual improvements passkeys bring to everyday authentication.

What is the RP ID?

The RP ID is another detail that becomes extremely important when you move from local development to production.

RP stands for Relying Party. In this case, your application is the relying party because it relies on the authenticator to prove the user's identity.

The RP ID is normally your application's domain or an appropriate registrable domain scope.

It determines which website context a credential belongs to.

If you configure it incorrectly, passkeys that worked beautifully on localhost can suddenly fail in production.

It is especially important when dealing with:

• Subdomains.
• Separate frontend and API hosts.
• Development versus production environments.
• Preview deployments.
• Multiple products sharing authentication infrastructure.

Your expected origin and RP ID should be explicit configuration, not something you casually infer from whatever host header happened to arrive in a request.

Discoverable credentials and username-less login

Another nice part of passkeys is that they can support a completely username-less login experience.

Traditionally, your server needs to know the user's account first.

The user enters:

user@example.com

Your backend then looks up that user and figures out which authentication methods belong to the account.

Discoverable credentials can reverse that flow.

The browser or authenticator can present credentials that match the current relying party before your server knows which account the user wants.

The user can select a passkey, authenticate, and the resulting credential tells your backend which account owns it.

This is how you can build a login screen where the user does not type an email address at all.

You can also keep a username-first flow.

In that version, the user enters an email address first. Your backend finds the credentials associated with that account and sends those credential IDs in allowCredentials.

The browser then knows which credentials are acceptable for that specific authentication attempt.

Both approaches are valid.

Personally, I find the discoverable flow much more interesting because that is where passkeys stop feeling like "passwords but with a fingerprint" and start changing the actual login experience.

Synced passkeys versus device-bound credentials

One phrase you will often hear is:

The private key never leaves your device.

That is a useful beginner explanation, but with modern synced passkeys it can also become misleading if taken too literally.

Some passkey ecosystems can securely synchronize a user's credentials across devices through a credential provider.

That is how a passkey created on one device may later appear on another device belonging to the same user.

The MDN passkeys guide is a useful reference if you want to dig further into synced passkeys, authentication flows, and credential management.

From your application's point of view, the important guarantee remains the same:

Your application never receives the private key.

You do not export it from WebAuthn, store it in your database, or send it back to the browser during authentication.

How a passkey provider protects or synchronizes its credential material is part of that provider's security architecture.

Other credentials may be device-bound.

For example, a hardware security key may contain a credential that remains associated with that physical authenticator.

This distinction matters when thinking about recovery and cross-device usage.

What should the frontend do?

One mistake I initially expected to make was thinking that implementing passkeys would involve writing a lot of cryptography in the frontend.

Thankfully, it should not.

The frontend's job is mostly orchestration.

It asks your backend for WebAuthn options, passes those options into a WebAuthn-capable browser API or client library, and sends the resulting response back to the server.

The browser and authenticator handle the sensitive cryptographic operations.

async function registerPasskey(deviceName?: string) {
  const options = await post('/api/passkeys/register/options')
  const response = await startRegistration({ optionsJSON: options })

  return post('/api/passkeys/register/verify', {
    response,
    deviceName,
  })
}

async function signInWithPasskey() {
  const options = await post('/api/passkeys/authenticate/options')
  const response = await startAuthentication({ optionsJSON: options })

  return post('/api/passkeys/authenticate/verify', { response })
}

The frontend should not be trusted to decide whether authentication succeeded.

It should not say:

The browser returned something, therefore the user is authenticated.

The backend still has to verify the cryptographic response.

The frontend also needs to handle the less glamorous UX cases:

• The user cancels the passkey prompt.
• No compatible authenticator is available.
• The ceremony times out.
• The challenge expires.
• The browser does not support the required flow.
• The requested credential cannot be found.

A cancelled fingerprint dialog is not necessarily a server error.

Your UI should treat user cancellation as a normal outcome rather than showing some terrifying red error banner every time someone changes their mind.

What should the backend do?

The backend is where most of the security-sensitive verification happens.

I would strongly avoid implementing the WebAuthn parsing and cryptographic verification yourself.

This is exactly the kind of protocol where using a mature, maintained library is much better than trying to be clever.

Your backend is responsible for things such as:

• Generating secure registration and authentication challenges.
• Creating WebAuthn options.
• Associating registration with the correct authenticated user.
• Verifying registration responses.
• Saving credential public information.
• Looking up credentials during authentication.
• Verifying authentication assertions.
• Updating relevant credential state.
• Creating the final application session.

// Registration options
const options = await generateRegistrationOptions({
  rpID,
  rpName,
  userID: encodeUserId(user.id),
  userName: user.email,
  excludeCredentials: existingCredentials,
  authenticatorSelection: {
    residentKey: 'preferred',
    userVerification: 'required',
  },
})
await saveShortLivedChallenge(event, options.challenge)
return options

// Registration verification
const challenge = await consumeChallenge(event)
const result = await verifyRegistrationResponse({
  response: body.response,
  expectedChallenge: challenge,
  expectedOrigin: passkeyOrigin,
  expectedRPID: rpID,
  requireUserVerification: true,
})
if (!result.verified) throw unauthorized()
await credentials.insert({
  userId,
  credentialId: result.registrationInfo.credential.id,
  publicKey: result.registrationInfo.credential.publicKey,
  counter: result.registrationInfo.credential.counter,
})

// Authentication verification
const challenge = await consumeChallenge(event)
const credential = await credentials.findByCredentialId(body.response.id)
if (!credential) throw unauthorized()
const result = await verifyAuthenticationResponse({
  response: body.response,
  expectedChallenge: challenge,
  expectedOrigin: passkeyOrigin,
  expectedRPID: rpID,
  requireUserVerification: true,
  credential,
})
if (!result.verified) throw unauthorized()
await credentials.updateCounter(credential.id, result.authenticationInfo.newCounter)
return issueSession(credential.userId)

The code itself doesn't look particularly scary.

The dangerous part is getting the assumptions around it wrong.

In production, you need to care about exact origin and RP ID configuration, challenge lifetime, replay protection, authorization, account state, secure cookies, rate limiting, credential-management permissions, and recovery.

Your authentication endpoint should not create a session until the WebAuthn response has been fully verified.

Your credential deletion endpoint should not remove a passkey just because someone knows its credential ID.

Your registration endpoint should not allow someone to attach a passkey to another user's account.

These things sound obvious when written down, but most authentication vulnerabilities live in exactly these surrounding application rules rather than in the cryptography itself.

What about signature counters?

You will often see a counter stored alongside a WebAuthn credential.

Historically, authenticators could increment a signature counter whenever the credential was used. The server could compare the new value against the previous one.

If the server saw something strange, such as a counter unexpectedly moving backward or being reused, it could potentially indicate that a credential had been cloned.

In practice, you should not build your entire passkey security model around signature counters.

Different authenticators behave differently, and some modern authenticators or synced passkeys may not give you a useful monotonically increasing counter in the way older explanations of WebAuthn sometimes imply.

The correct approach is generally to let your WebAuthn library handle the protocol behavior and store the counter information it expects, rather than inventing your own cloned-authenticator detection logic.

Metadata is part of the product experience, not just the protocol

The cryptographic side of passkeys gets most of the attention, but there is another layer that matters a lot once you actually ship this to users: credential management.

If someone has four passkeys, they need some way to understand what they are looking at.

A settings page might show:

• Windows laptop — added August 21 — last used today.
• 1Password — added August 12 — last used August 25.
• Security key — added July 3 — last used August 1.

WebAuthn does not automatically give you a perfect human-readable name for every credential.

Your application may need to create that layer.

For example, when a user creates a passkey, you might ask:

What should we call this passkey?

Or you might create a generic name and let them edit it later.

You can also store application metadata such as:

• When the credential was registered.
• When it was last successfully used.
• A user-defined name.
• Whether your application considers it a recovery credential.
• Potentially browser or authenticator information where appropriate.

You should be careful not to turn this into invasive device fingerprinting just because you can collect metadata.

Store what genuinely improves security or usability.

Credential management deserves its own security rules

Once passkeys exist, users need to be able to manage them.

Usually that means allowing them to:

• See registered passkeys.
• Add another passkey.
• Rename a passkey.
• Remove a lost or old passkey.
• Potentially see when each passkey was last used.

These actions are security-sensitive.

Imagine an attacker manages to hijack a user's browser session for five minutes.

If they can silently add their own passkey, they may turn a temporary session compromise into persistent access.

That means adding or deleting authentication methods may deserve stronger protections than editing a profile photo.

Depending on the value of the account, you might require recent authentication, another passkey confirmation, a notification to the user, or additional recovery controls when credentials change.

Recovery is part of passkey authentication

Passkeys solve a lot of password problems, but they do not remove the concept of account recovery.

Users lose phones.

Laptops die.

People forget device PINs.

Security keys disappear.

Cloud accounts get locked.

A serious passkey implementation needs to answer:

What happens now?

Synced passkeys make this easier because a user's credentials may become available again through their platform account on a new device.

But you cannot assume that every user will always have access to a synced credential.

One useful strategy is allowing users to register multiple passkeys.

For example:

• Laptop passkey.
• Phone or synced-provider passkey.
• Hardware security key.

Then losing one authenticator does not necessarily mean losing the entire account.

You can still provide another recovery method, but remember something important:

Your account is only as secure as its easiest recovery path.

If the user has incredibly strong phishing-resistant passkey authentication but an attacker can click Forgot access? and take over the account through a weak recovery email flow, your passkey implementation has not achieved nearly as much as it appears to have achieved.

Can passkeys work on another computer?

Yes.

This confused me initially because "the private key is on your device" makes it sound like a passkey should be permanently trapped inside one machine.

There are several ways cross-device authentication can work.

A synced passkey may already be available through the user's credential provider on another device.

A phone can also be used as an authenticator for a nearby computer.

You may have seen this flow already: the computer displays a QR code, you scan it with your phone, confirm that the devices are nearby, authenticate on your phone, and the computer's browser completes the login.

A hardware security key can simply be moved between supported computers.

The exact UX depends on the browser, operating system, authenticator, and credential provider, but passkeys are not inherently limited to the device on which they were originally created.

Passkeys make authentication feel simpler because the complexity moved somewhere better

That is probably my biggest takeaway from learning how passkeys actually work.

Passwords put a surprising amount of responsibility on the user.

We ask people to invent secrets, remember them, avoid reusing them, detect phishing websites, use password managers, and sometimes type another six-digit code afterward.

Then we blame them when one of those steps goes wrong.

Passkeys move much of that responsibility into browsers, authenticators, operating systems, credential providers, and well-defined cryptographic protocols.

The user sees:

Click. Fingerprint. You're in.

Underneath that, however, quite a lot has happened.

Your backend generated a fresh challenge. The browser checked the relying-party context. The authenticator found the correct credential. The user locally unlocked that authenticator. The private key signed the authentication data. The server found the corresponding public key and verified the signature. Only then was the authenticated session created.

And throughout that whole process, the private key never needed to be sent to your application.

That is the part that makes the system so interesting.

The experience became simpler without making the authentication model simpler or weaker underneath.

In the next article, I'll take this into actual code and build the registration, authentication, credential-management, and recovery flow using Vue, Nuxt, and a WebAuthn library on the backend.