Passkey Implementation: Misconceptions, pitfalls and unknown unknowns

Original Article ↗ Hacker News Discussion ↗

Passkeys, the WebAuthn-based replacement for passwords, are drawing both enthusiasm and frustration as developers grapple with real-world implementation details. Commenters highlight UX challenges, cross-device quirks, and the complexity of mixing passkeys with existing flows, while also debating platform lock‑in, attestation, and the lack of easy export or migration between providers. Despite these concerns, many see passkeys as a major security upgrade for non-technical users and expect adoption to grow, often via SSO and password managers rather than bespoke implementations.

Implementation difficulty

  • Some describe passkey/WebAuthn as a “giant mess”: confusing options (discoverable vs non‑discoverable, username vs usernameless), browser quirks, and timing of prompts.
  • Others report it’s quite manageable: ~40 hours to add to an existing app, or even a weekend project, especially using existing libraries.
  • Several note that vendor content may exaggerate complexity to sell services, but still acknowledge real edge cases and bugs.

UX and account management

  • Common advice: allow multiple passkeys per account and let users name/rename them, showing device/browser, creation date, and “synced” vs device‑bound status.
  • Managing both passkeys and traditional flows (password, OTP, social login) introduces race conditions and UX edge cases, especially around email/phone verification.
  • Cross‑device flows (QR + Bluetooth) are fragile; people report failures on Windows/Android despite working Bluetooth. Some OS versions seem to behave differently.

Security model and benefits

  • Supporters emphasize: strong phishing resistance, no password reuse across sites, and hardware‑backed storage that resists keylogging and database leaks.
  • Critics argue: good passwords in a manager already solve their threat model; security improvements mostly help non‑manager users.
  • Clarification: passkeys are WebAuthn resident credentials; biometrics (finger/face) only unlock local storage—PIN/password fallback remains.

Lock‑in, attestation, and portability

  • Major concern: attestation plus ecosystem power could enable “approved devices only” and lock out new or self‑hosted authenticators.
  • Some examples already show government and large sites restricting which hardware tokens are allowed, or gating passkeys by user agent.
  • Others say current passkey use rarely enforces attestation and AAGUIDs are spoofable, but agree the risk is real and must be steered carefully.
  • Lack of export/import is a major sticking point; people fear being trapped in Apple/Google/password‑manager silos. Work on interoperable export is mentioned but timelines are “unclear.”

Federation vs direct passkeys

  • One camp expects most apps to “get passkeys via SSO” (OIDC, Sign in with X), with direct passkeys mostly for big brands or admin/break‑glass accounts.
  • Others counter with adoption lists and argue passwords coexisted with social login, so direct passkeys will also persist, especially for B2C security gains.

Adoption and ecosystem maturity

  • Some developers are deferring adoption until standards, browsers, and cross‑device flows stabilize.
  • Others report strong user satisfaction where passkeys work, and point to big‑platform numbers and improved 2FA uptake as evidence they’re becoming mainstream despite rough edges.