上个月帮朋友排查一个后台问题，打开浏览器控制台一看，登录请求返回200，但跳转后页面又弹回了登录页。查了半天，发现是Cookie的SameSite属性被设成了Strict，跨站跳转时浏览器直接不发送这个Cookie。这种坑踩过一次就忘不了。

Web登录这件事，表面看就是填个用户名密码、点个按钮。但背后牵扯的东西比多数人想象的多。一个完整的登录流程至少涉及：前端表单提交、HTTPS传输、后端验证凭据、生成会话标识、写入Cookie或返回Token、后续请求携带凭据、服务端校验凭据有效性。每一步都有翻车的可能。

最早期的做法很简单——HTTP Basic Auth。浏览器弹出一个原生对话框，用户输入账号密码，浏览器把它用Base64编码后塞进Authorization头里，每次请求都带着。问题是Base64不是加密，等于裸奔。而且没有退出机制，除非关浏览器。现在基本只有内部工具还在用。

后来主流方案换成了Session + Cookie。用户提交账号密码，服务端验证通过后在内存或数据库里生成一条Session记录，把Session ID通过Set-Cookie写给浏览器。浏览器后续每次请求自动带上这个Cookie，服务端拿Session ID一查就知道是谁。这套机制跑了几十年，稳。但有个麻烦：服务端得存Session。用户量大了，要么用Redis集中管理，要么做粘性会话，运维成本上去了。多台服务器之间同步Session也是个烦人事。

Token方案就是冲着这个痛点来的。服务端不存了，把用户信息编码进一个Token里，签名后发给客户端。客户端自己保存，每次请求带上。服务端只需要验证签名就能确认身份。JWT是这套思路里最流行的格式。但JWT有个被很多人忽略的问题：签发后无法撤销。用户改了密码、管理员封了账号，旧Token在过期前依然有效。所以实际项目里常见折中做法——JWT设短过期时间，配合一个Refresh Token来续期。

前端存Token的位置也有讲究。放localStorage里，XSS攻击一打一个准，恶意脚本直接读走。放httpOnly的Cookie里，JS读不到，但CSRF又来了。所以你看，安全这东西从来不是某个方案能一劳永逸解决的，得组合着来。

说个我实际见过的案例。某电商网站登录接口没有做频率限制，我用Burp Suite跑了个字典，十分钟就撞出了一个测试账号的密码。后来他们加了图形验证码和IP限流才算堵上。登录接口是所有系统的门面，也是最容易被攻击的入口。暴力破解、撞库、凭证填充，这些攻击每天都在发生。

密码存储本身也是个大坑。见过用MD5存密码的项目，也见过明文存的。正确做法是用bcrypt或argon2这类慢哈希算法，每个用户加独立盐值。计算成本调高一点，让暴力破解的代价大到不划算。这不是什么高深技术，但就是有人偷懒。

现在Passkey开始慢慢铺开了。用生物识别或者设备PIN代替密码，基于公钥密码学，服务端只存公钥，私钥留在用户设备上。没有密码可以泄露，也就没有撞库这回事。苹果、谷歌、微软都在推。不过迁移成本摆在那，中小项目短期内不太可能全面切换。

登录功能写起来可能就几十行代码，但要写得安全、写得让人用着舒服，需要考虑的东西一点不少。下次再遇到登录跳回原页面的bug，先看看Cookie的SameSite和Secure属性，大概率就是它。