方案 - 前后端分离的用户授权

基本原理

用户通过前端页面登录成功后后端返回token字符串，前端将token存入localStorage中，之后前端所有的数据请求都携带token（token可以放在请求头或请求参数里，只要跟后端约定好）。后端拿到token后校验token是否有效，如果有效则继续进行业务处理，无效则返回错误信息。在这段原理描述中产生了一个问题：如何生成和校验token。下面提供两种方案供参考：

方案一：将用户ID + 登录IP + 登录时间点的时间戳进行AES加密

校验：后台获取到token后对token进行解密，首先判断token是否过期（登录时间+有效时间是否小于当前时间）。如果已经失效，则返回“token失效”，前端跳转登录页面重新获取token。如果未失效，则校验请求IP和token中的IP是否一致，如果不一致视为token泄漏，返回“非法请求”（如考虑更换网络的情况则不应当加上该限制）。
优点：独立完成，不依赖缓存和数据库；失效时间可以灵活配置并实时生效；
缺点：token可计算；加密密钥不易管理，一旦泄漏很容易造成用户攻击；加密密钥不易更改，一旦更改所有token都将失效；token泄漏容易造成用户攻击；

方案二：随机生成一个N位（建议64位）的随机字符串作为token字段，将用户ID、登录IP、登录时间等信息作为辅助字段存入数据库和缓存（如Redis）

校验：后台获取到token后，将token作为key先从redis中获取记录，如未获取到则从数据库中获取，如都未获取到记录则视为非法token。如获取到了记录，则可从记录中获取用户信息、登录IP、失效时间并对其进行校验。
优点：无法通过计算的方式获得token，缓存和数据库中没有记录的token都是无效的；失效时间可以灵活配置并实时生效；
缺点：通过大量无效的token发送请求会增加数据库压力甚至导致数据库崩溃；token泄漏容易造成用户攻击；
优化：为了解决“无效token攻击”，可以给token设定一个格式并进行初步校验，如token的1~10位为数字、11位～20位为英文等。通过设置独特的token格式可以增加攻击难度，但前提是能对token格式进行有效的安全管理，一旦泄漏依然可能造成“无效token攻击”。

（完）