基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录
- 前端使用用户名跟密码请求首次登录
- 后服务端收到请求，去验证用户名与密码是否正确
- 验证成功后，服务端会根据用户id、用户名、定义好的秘钥、过期时间生成一个 Token，再把这个 Token 发送给前端
- 前端收到 返回的Token ，把它存储起来，比如放在 Cookie 里或者 Local Storage 里
- 前端每次路由跳转，判断 localStroage 有无 token ，没有则跳转到登录页。有则请求获取用户信息，改变登录状态；
- 前端每次向服务端请求资源的时候需要在请求头里携带服务端签发的Token
- 服务端验证token，校验成功则返回请求数据，校验失败则返回错误码，前端得到 401 状态码，重定向到登录页面。
token的特点
- 可以避开同源策略(实现单点登陆SSO)
- 可以避免csrf（跨站请求伪造）攻击
- 无状态、可在多个服务间共享
token的有效期问题
根据系统的安全需要，token最好尽可能的短，但是也不能太短，会一直让用户去登录。
两种方案解决token过期问题
-
服务端保存 Token 状态，用户每次操作都会自动刷新（推迟） Token 的过期时间（类似防抖的思想）--Session 就是采用这种策略来保持用户登录状态的。但是不断请求接口修改token成本较高，所以通常为了提升效率，减少消耗，会把 Token 的过期时保存在缓存或者内存中。 -
使用 Refresh Token，服务端不需要刷新 Token 的过期时间，一旦 Token 过期，就反馈给前端，前端使用 Refresh Token 申请一个全新 Token 继续使用。服务端只需要在客户端请求更新 Token 的时候对 Refresh Token 的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。前端登录 --> 服务端创建Token和Refresh Token返回给前段 前端请求数据（带着token）--> 服务端验证token（token过期）--> 前端根据Refresh Token重新请求token --> 服务端根据Refresh Token重新生成token传给前端 --> 前端带着新token重新请求数据 --> 业务结束
安全考虑
- Refresh Token 有效时间较长，所以它应该在服务器端有状态，以增强安全性，确保用户注销时可控
- 应该考虑使用二次认证来增强敏感操作的安全性（极验，或短信验证码等）
手机扫码登陆流程
image.png
单点登录
前提：只要是不同业务间服务端采用相同的密钥和算法来认证token的有效性就可以实现单点登录
单点登录的本质是跨域的不同项目之间的cookie、token共享的问题解决。
那么不同的域名之间怎样进行token的传递呢
iframe+postMessage实现跨域资源传输，然后通过localStorage把token记录在当前域名下（方案失败 ❌）
Domain A
|---- iframe A ----postMessage---- iframe B => Set localStorage ❌
ios中 iframe 里写入B域名的localStrage不成功
通过node层接口请求实现token传递（方案失败 ❌）
将Domain A的node的借口调用设置CORS允许Domain B访问
然后Domain B请求Domain A上的cookies里的token，然后写到Domain B的cookie上。
跨域请求带跨域cookies的方法逐步被浏览器禁用了。高版本ios和高版本chrome都已禁用
通过node的redis进行token传递 ✅
Domain A的node中将token存在redis中，key作为随机id
然后重定向到Domain B的页面将key带到url上，Domain B的url上取到key
Domain B的node服务根据key在redis中读到相应的token然后储存到自己的cookie上。
完成token的传递
