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

怼烎@ 2022-04-03 04:11 314阅读 0赞

### 基本原理 ###

用户通过前端页面登录成功后后端返回`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攻击”。

（完）