token登录验证

登录验证这事儿，录验说白了就两种路子：一种是录验服务端记着你是谁，另一种是录验服务端发你一张“通行证”，你每次来都亮一下。录验

token就是录验那张通行证。用户输入账号密码，录验服务端验证通过，录验签发一个加密字符串，录验客户端存起来。录验以后每次请求，录验带上这个字符串，录验服务端一验，录验哦，录验是录验你，放行。录验

session那套老办法呢？服务端得开一块内存专门存你的登录状态。用户一多，服务器内存吃紧，还得考虑分布式环境下session怎么同步。头疼。

token的好处就在这——服务端不用存任何状态。你拿来的token，我解个密，验个签名，就知道你是谁，该给你看什么。无状态，天然适合分布式和微服务架构。我去年给一个电商平台做重构，原来用session，一到促销季就得加机器扛session同步，换了JWT之后，横向扩展随便加，后端彻底轻松了。

但token不是没坑。最大的坑是——它一旦签发，在有效期内就永远有效。你密码改了，旧token还能用。你账号被盗了，token被偷了，除非等它过期，否则一点办法没有。我见过某家公司的内部系统，token有效期设了7天，结果员工电脑被黑了，攻击者拿着token在系统里逛了整整一周，管理员只能干瞪眼。

所以现在靠谱的做法是双token：一个短期access token，15分钟过期，真正访问资源用；一个长期refresh token，7天过期，只用来换新的access token。access token丢了问题不大，15分钟后自动失效。refresh token丢了？那得配合设备指纹、IP变动检测来兜底。

有人可能会问，既然token这么好，为什么还有公司在用session？因为简单啊。中小项目，单机部署，session机制写起来比token快多了，而且可以随时在服务端把某个用户踢下线——token做不到这点，除非你引入黑名单或者状态版本号，那又回到有状态的老路了。

我个人的看法是：别迷信token，也别死守session。看场景。如果是内部的低并发管理系统，session完全够用；如果是面向公众的高并发API服务，token是更优解。但无论选哪种，都得想清楚token的失效策略、续期机制、以及被窃取后的应对方案。

对了，还有一点容易被忽略——token别放在localStorage里。XSS攻击一打，全没了。放内存变量里，刷新页面就丢，体验差。折中方案是放cookie里，设HttpOnly，至少挡住大部分XSS窃取。当然，CSRF防护又得跟上。安全这东西，永远是攻防博弈，没有银弹。