一、什么是登陆凭证#
**登录凭证（Login Credentials）**是向系统证明「我是我」的一组信息。系统不会凭空相信你，必须先核对凭证，才让你进入账户、访问数据、调用接口、分配相应权限。
凭证一定要做好保护，无论是用户还是开发者。
当用户凭证被攻击者拿走，就相当于账号被盗了。举个例子，Cursor 的用户凭证是存到 Cookie 中的信息，头是 WorkosCursorSessionToken；当你把这个凭证放到互联网上（之前薅羊毛），群众中的坏人拿着你的 Token 就把你账号注销了。
对于开发者来说更要把用户凭证做好保护，防止用户信息、财产损失。需要做好加密以及更新。
二、解决办法#
一般方案（Cookie、Session）#
用户完成登陆 → 服务器保存用户信息（Session） → 并将 Session 信息返回给前端 → 前端将其保存至浏览器 Cookie 中 → 每次请求将 Cookie 信息携带至请求体发送给后端 → 后端每次进行验证。
致命缺点： 在多个服务器的情况下，Session 只保留在登陆的那台机器上面，后续请求打到别的机器上就判定为未登录。
Redis 保存 Session#
将 Session 保存至 Redis 中，无论多少服务器都能在 Redis 中找到 Session 进行校验。
需不需要设置过期时间？
这是肯定的。如果没有过期时间，用户岂不是一直处于登陆状态？这样可太坏了。
那过期时间设置多少呢？
用户不可能到一定时间就要重新登陆，所以这个过期实际是一个假过期：当用户正常使用时，服务端需要刷新用户的 Token，确保用户这段时间是在用的。等用户一段时间不用了，Redis 过期时间会自动把用户踢出登陆。
致命缺点：
服务端每次验证都要去查 Redis，对双方的压力都是不小的。
JWT#
如果要减少 Redis 的压力，那么校验这一块就不能去 Redis 中。
服务端通过 JWT，将用户信息保存到 Token 中返回给前端，后续每个请求只需要本地校验即可。
优势：
减少服务端的压力、不需要查 Redis、扩展简单、适合分布式。
缺点：
JWT 是无状态的。攻击者只要拿到了用户的 JWT 凭证，只要没有过期就存在危险。不能踢出用户、限制用户。
双 Token（AccessToken、RefreshToken）#
服务端维护两套 Token。
AccessToken 用于校验用户信息，过期后自动换新；如果丢失，只存在短时间危险。服务端如果要踢用户下线，只需要将保存的 RefreshToken 删除即可。
| AccessToken | RefreshToken | |
|---|---|---|
| 用途 | 日常访问 API | 只用来换新的 AccessToken |
| 有效期 | 短（1 ~ 2h） | 长（7天 ~ 30天） |
| 携带频率 | 每次请求都带 | 几乎不带，只在刷新时用 |
| 泄露风险 | 高（频繁传输） | 低（很少出现） |
无感续签#
总结#
没有最好的方案，只有最适合的办法，结合场景和现在实际情况考虑。
三、后续升级#
会话安全： Token Family、Refresh Token 重用检测、单设备/全设备下线、Session 版本校验，使被撤销的 Access Token 可立即失效。
安全防护与审计： 补齐 CSRF、CORS、刷新接口限流、异常刷新检测，并记录登录、刷新、撤销日志。
平台化演进： 网关统一鉴权，Redis 管在线会话、数据库留审计历史；权限中心处理权限变更与缓存失效；高风险操作接入 MFA/风控，后续升级到 OAuth 2.1、OIDC、SSO。