The Copenhagen Book: general guideline on implementing auth in web applications

Overall reception of “The Copenhagen Book”

• Many commenters find it clear, practical, and a welcome contrast to “don’t roll your own auth” warnings.
• It’s praised for being concise, actionable, and focused on how to use crypto/auth correctly rather than deep math.
• Some skepticism about treating it as authoritative, partly due to concerns about some design recommendations (e.g., session extension).

Passwords, magic links, and alternative auth flows

• Strong disagreement over “don’t support passwords in 2024”:
  • One side: passwords are universal, work well with managers and TOTP/security keys, and shouldn’t be removed.
  • Other side: email magic links / OTPs are more secure in practice for typical users than reused passwords.
• Magic links draw heavy criticism for UX: email delays, spam filters, device mismatch (phone vs desktop), and corporate email gateways “clicking” links.
• Some argue magic links should only log you in on the device that clicked them to reduce phishing, accepting worse UX on public computers.

Passkeys, OAuth, and centralization

• Predictions that integrated password managers or passkeys will dominate; others are wary of centralization (Apple/Google lock-in, account bans).
• Concerns that OAuth and passkeys leak usage patterns to big providers and create brittle dependencies, so passwords should remain an option.

Security vs UX and library design

• Repeated theme: many real security failures are UX and API-design problems, not cryptographic ones.
• Crypto APIs are criticized for “character soup” names and unsafe defaults; praised examples favor high-level, purpose-driven functions with safe defaults.
• Good UX examples: simple password hashing APIs, well-integrated hardware keys; bad UX: cumbersome security key flows and PGP-style complexity.

Sessions, tokens, and lifetimes

• Debate around extending session lifetimes vs regenerating tokens:
  • Some worry about effectively “immortal” tokens.
  • Others argue rolling sessions with DB lookups and user-visible session management are a reasonable tradeoff.
• Long-lived sessions are desired by users frustrated with frequent expirations and 2FA prompts; others note risk and provider-imposed caps.

Email handling and identifiers

• Disagreement about treating email addresses as case-insensitive:
  • Standards say local parts are case-sensitive, but most real systems are not.
  • Common compromise: store original casing for display, but compare case-insensitively.
• Notes that many transactional email providers only support ASCII and that exotic email formats are often painful in practice.

Other gaps and wishes

• Requests for coverage of JWT, SAML/SSO, ID tokens, and more language examples (Python/Node).
• Some see the “how to build” approach as preferable to ever-more-complex auth libraries.