Evaluate WebAuthn and passkeys

Protocol roles

The relying party is the web service that registers and verifies credentials. The client is the user agent that enforces origin and WebAuthn API rules. The authenticator creates and uses a credential private key. The user authorizes an operation through presence or verification. CTAP is a separate protocol that a client platform can use to communicate with an external authenticator.

A passkey is a WebAuthn credential designed for user authentication. It can be device-bound or sync through a credential provider. "Passkey" does not state whether the credential is synced, whether attestation was accepted, or which user-verification method protected it.

WebAuthn Level 2 is the final W3C Recommendation baseline. As of August 2026, WebAuthn Level 3 is a Candidate Recommendation Snapshot. Treat Level 3-only behavior as draft-stage until the deployment's supported browser and authenticator profiles prove it.

Message flow

During registration, the relying party creates a unique challenge and supplies its relying-party identity, user handle, algorithms, authenticator-selection policy, and attestation preference. The browser allows the operation only in an eligible origin context. The authenticator creates a credential key pair scoped to the relying-party ID and returns an attestation object and client data. The relying party verifies the challenge, origin, relying-party ID hash, type, user presence, required user verification, algorithm, credential identifier, and attestation policy before it stores the public key and counter or backup state.

During authentication, the relying party sends a new challenge and credential selection policy. The authenticator finds an eligible credential, confirms user presence or verification, and signs authenticator data plus a hash of client data. The relying party verifies the challenge, origin, relying-party ID hash, operation type, flags, signature, credential ownership, and relevant counter or backup-state behavior before it creates a session.

The challenge binds freshness. The origin and relying-party ID bind the ceremony to a web identity. The signature proves possession of the credential private key. User verification states that the authenticator performed its configured local verification. None of these properties performs application authorization.

Validation and failure cases

Use at least 128 bits of server-generated challenge entropy, bind the challenge to one short-lived transaction, and consume it once. Verify the exact expected origin, including scheme and port rules. Verify the relying-party ID hash and reject an ID outside the permitted domain scope. Check type, challenge, user-presence flag, required user-verification flag, credential identifier, algorithm, signature, and user binding.

Define attestation policy before registration. No attestation or self-attestation can be suitable for broad consumer authentication. Managed device assurance can require stronger enterprise evidence. Attestation does not prove the person identity by itself.

Test a challenge replay, another origin, a sibling or parent-domain mistake, wrong relying-party ID, absent user verification, credential registered to another account, cloned or reset signature-counter behavior, enrollment into an already authenticated but hijacked session, and recovery that bypasses passkey strength.

Design tradeoffs and residual risk

WebAuthn is phishing resistant because a credential is scoped to the relying-party ID and the client includes the real origin in signed ceremony data. Users do not enter a shared secret at a look-alike site. This does not stop session-cookie theft after authentication or malicious action within the correct origin.

Synced passkeys improve availability and device migration. Their protection depends on the credential provider's account, recovery, device, and sync security. Device-bound credentials can give stronger locality but increase enrollment and recovery work. Attestation can improve authenticator assurance but adds privacy, supply-chain, metadata, and lifecycle concerns.

Account recovery is often the weakest path. A password or support reset that can replace a passkey reduces the effective assurance to that recovery process. Record recovery, new-device enrollment, passkey deletion, and high-risk reauthentication as part of one control.

Pomerium boundary

Pomerium delegates user authentication to a configured identity provider. Whether a Pomerium-protected session used WebAuthn, a synced passkey, a device-bound credential, or another factor depends on provider configuration and claims that Pomerium can reliably require and validate. Operators own provider policy, recovery strength, and step-up requirements. Pomerium then applies route policy to its own session.

Exercise

Register and authenticate one test account with a platform passkey and one external security key. Record relying-party ID, origin, challenge lifetime, user-verification requirement, attestation mode, discoverability, backup eligibility and state, and recovery methods.

Run negative tests from a look-alike origin, with a replayed challenge, without required user verification, and after account recovery. Confirm that the relying party rejects invalid ceremonies and that recovery does not silently establish a stronger assurance claim than it performed.

Evaluation checklist

• Are relying-party ID, origin, challenge, type, flags, signature, and credential ownership all verified?
• Is every challenge unique, short-lived, server-generated, bound, and consumed once?
• Does the system distinguish device-bound, synced, discoverable, attested, and user-verified properties?
• Are recovery and new-device enrollment held to the intended assurance level?
• Is Level 3 behavior identified as Candidate Recommendation guidance rather than a final standard?