The Copenhagen Book: general guideline on implementing auth in web applications
A new online guide, *The Copenhagen Book*, aims to give practical, technology-agnostic advice on implementing authentication in web applications, and has been widely praised for being clear and actionable compared to typical security resources. Commenters debate the trade-offs between passwords, email magic links, OAuth, passkeys, and hardware keys, emphasizing that usability, user risk profiles, and sensible defaults matter as much as cryptographic strength. They also highlight implementation nuances—such as session lifetimes, token rotation, email handling, and library design—as areas where small choices can have large security and UX impacts.
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.