Federated login and passkeys

Add passkeys with WebAuthn

Understand registration and authentication ceremonies, server challenges, relying-party scope, public-key storage, and recovery planning.

8 minute lesson

~~~

Passkeys use WebAuthn public-key credentials. The authenticator keeps the private key; the server stores credential identifiers and public-key material.

The server generates an unpredictable challenge for each ceremony and verifies origin, relying-party ID, challenge, signature, and required flags with a maintained WebAuthn library. Registration and authentication need HTTPS in production. Plan more than one credential and a secure recovery path.

Registration and authentication are separate ceremonies.

During registration, the server creates options with a fresh challenge and relying-party identity. The authenticator creates a credential for that relying party. The server verifies the response before storing the credential ID, public key, and metadata needed by its library.

During authentication, the server creates another challenge. The authenticator signs over that challenge and origin-bound data. The server verifies the signature with the stored public key.

Store challenges for a short time and consume them once. Bind each one to the session or account, ceremony type, expected origin, relying-party ID, and user-verification policy. A registration response cannot satisfy an authentication ceremony, and a challenge started in one browser session cannot be redeemed in another. Verify user presence and user verification according to policy, and ensure the returned credential and user handle belong to the intended account. Check the library’s counter and backup-state behavior without assuming every authenticator uses counters the same way.

Passkeys resist phishing because credentials are scoped to a relying-party ID. They do not remove account-lifecycle work. Users change devices, sync providers, lose authenticators, and need to name or remove credentials.

Require recent authentication to add a passkey to an existing account. Otherwise, a stolen session can become a durable new login method.

Test sign-in, replayed challenge, a challenge swapped between two sessions, wrong ceremony type, wrong origin, wrong relying-party ID, credential removal, and an attempt to enroll through an old session.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →