Dual Tokens Beat Homegrown Crypto Auth for Most Web Apps
Building authentication on homegrown browser crypto instead of a standard token lifecycle invites XSS, replay, and key-exposure risks; the article's conclusion gives teams a defensible default: use dual tokens for sessions and bring in WebAuthn only when you need passwordless login or device binding.
The article compares the two common auth approaches: dual token (Access Token + Refresh Token) and front-end public/private key authentication used to exchange for a token. It concludes that dual tokens should be the default for most web apps because they cleanly separate short-lived access credentials from long-lived renewal credentials. Dual tokens work well with JWT, OAuth, and OIDC, and teams already understand the lifecycle.
Public/private key auth solves a different question: proving that the client holds a particular key. That makes it useful for passwordless login and device binding, but it does not replace token session management. The author warns that private keys in the browser are not server secrets; non-exportable Web Crypto keys can still be called by malicious scripts during page execution, and embedded strings are effectively public. WebAuthn/Passkey is the recommended standard for client-key authentication.
The recommended approach is to combine them: use WebAuthn or public/private keys for login, then issue short-lived Access Tokens and rotating Refresh Tokens for the API session. Security depends not on the algorithm but on token lifecycle, storage, XSS/CSRF protection, and revocation design.
The article cuts through the common misconception that using crypto in the browser automatically improves security; the real risk shifts to key storage and token lifecycle.
Teams often conflate authentication with session management; separating the two design decisions (proving identity vs. maintaining sessions) simplifies architecture and security reasoning.
Because front-end code is public, any private key embedded there is public too, which makes WebAuthn's hardware-backed keys the only realistic client-key path.