Passkey Implementation: Misconceptions, pitfalls and unknown unknowns

Original Article ↗ Hacker News Discussion ↗

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.