Stricter WebAuthn registration and assertion

WebAuthn only helps if the server rejects a response that does not match the challenge it just issued. Loose parsing of authenticator output is how malformed or unexpected payloads sneak through. Registration and assertion handling now enforce stricter verification and refuse those responses.

This is the longer note behind the July 18 changelog entry.

How it works

Passkeys use two ceremonies:

1. Registration — Authdog creates a short-lived challenge scoped to an environment and user. The browser calls navigator.credentials.create(). Authdog verifies the registration response before storing the credential.
2. Authentication (assertion) — Authdog creates another challenge. The browser calls navigator.credentials.get(). Authdog verifies the assertion before creating a session.

Verification already covered challenge, exact origin, relying-party ID hash, user-presence and user-verification flags, credential signature, credential ownership, expiration, one-time challenge consumption, and authenticator signature counters. This release tightens that path and rejects malformed or unexpected authenticator responses instead of attempting to accept a partial or oddly shaped payload.

Credentials and challenges stay isolated by environment. The relying-party ID comes from the identity host, so passkeys are bound to that site. Authdog supports ES256 and RS256 credential keys. Registration requests no attestation, so the ceremony is verified without collecting device-identifying attestation.

No new console switch. Hosted passkey flows pick up the stricter checks when Passkeys is enabled for the environment.

Set it up

1. Enable Passkeys for the environment in the Authdog console.
2. Register a passkey from an authenticated hosted session.
3. Sign out, then sign in with that credential.
4. Repeat with a platform authenticator and a roaming security key if you support both.
5. Confirm cancellation, a missing authenticator, and a replayed or edited response fail closed.

Keep at least one non-passkey method enabled during rollout. Test on the production-like HTTPS domain you will ship; WebAuthn origin rules make localhost a poor substitute.

Trust boundaries

A successful ceremony proves control of a credential at that moment. It is not a session by itself. Continue validating the Authdog session on every protected backend request.

Stricter verification fails closed on malformed input. That can surface clients or wrappers that used to send unexpected fields. Fix the client; do not look for a compatibility bypass on the server.

Biometric data never reaches Authdog. The authenticator handles user verification on-device. The WebAuthn response carries signed protocol data only.

Challenges are one-time and environment-scoped. Do not reuse a registration or assertion payload across environments or users.

Try it

Enable Passkeys in a development environment, register and assert, then try a cancelled and a malformed response. Guide: Passkeys. The original release note is in the changelog.