Session、Token、API安全设计
名词解释
- session 会话，维护用户状态。会话中关联了用户信息。
- token 令牌，用于签权。
很多人纠结于token是什么，session又是什么，但我认为，这就是两个单词，两个概念而已，就看你怎么去实现并使用了。
Session
session顾名思义就是会话，维护了用户的状态就是会话，这是为了解决http是stateless的问题发明的东西。
通常的用法是：
- 用户使用账号+密码/手机号+验证码登录
- 后台验证通过后会在Redis会话表里产生一条记录，这条记录就可以称为会话！记录里面有一个随机的唯一值和用户的信息，这个随机的唯一值会返回给客户端保存，以后的接口通过这个唯一值进行鉴权，这个唯一值可以称为sessionId。
- 后台接口带上sessionId，服务器拿到后去表里校验是否存在且有效，有效则鉴权通过，无效则报错
Token
Token翻译过来就是令牌，何为令牌，就是一个证明自己的证明。那拿刚才的sessionId来说，它又何常不是一个证明呢？它证明了我之前是登录过的，并且是有效的用户，所以我认为，刚才的sessionId也可以称为token，也有人认为那就是token。
看到这里估计又有人吐槽了，token的状态是保存在客户端的，session是服务端在管理状态。这么理解的人是认为，session管理需要在后台存表，管理这个状态，而token后台不需要保存，因为token里自带了信息，比如用户基本信息、过期时间等，后台每次收到直接解密校验即可，所以说token的状态是保存在客户端的。这么理解不是不可以，很多人也是这么用的，但有明确规定token就一定要带信息吗？别和我说JWT，JWT只是token的一种实现而已，不代表所有token都必须要有用户信息。我不反对有人这么理解，因为token和session本身就是概念，并不是规定，有不同的理解就可以有不同的实现。
鉴权方案
刚其实已经说到两种实现了，对于客户端来讲，拿到的就是一个字符串，并不关心它叫什么，也不关心服务端怎么去校验，只是每次请求里带上这个字符串就好了。
服务端校验的两种方式：
-
查表校验
这种方式就是session的通常用法了，服务端会建表，把所有用户的会话都存在Redis。这种方式是有好处的，可控度更高，要以随时把一个发出去的token/sessionId置为失效，这是保障安全的一个重要手段。如何随时失效呢？因为客户端每次请求带的token/sessionId都需要去Redis里查找看是否存在且有效，无效就无法访问了，是否有效由后台决定，失效操作可以进行逻辑删除或物理删除。
-
token自校验
这种方式就是用户登录后，服务端把用户信息和过期时间或一些其它信息进行加密处理，生成一个token返回给客户端，客户端下次带token上来时，服务端不需要去查表，因为这个token是带用户信息的，先对token进行解密，能解密出用户信息说明这个token是服务端签发的，再判断是否过期，如果没过期就有效。
此方案好处是不需要查表了，省去了后台session管理的一堆逻辑。也不需要考虑会话集群同步问题。但缺陷是这种token只能等它自动失效，无法由后台决定是否失效。当token被窃取进行恶意攻击时并没有很好的对策，看到这里就有人说了，定一个黑名单机制不就好了，如果定一个黑名单机制，不也一样要查表吗？那对比查表校验的优势又在哪呢？也会有人说把token的有效期设置短点不就安全了，但设置短了让用户频繁登录这种体验就很差了。
API安全设计
API的安全需要做好防窃取、防篡改、防重放等，安全都是相对的，要在安全和效率做权衡。所以有效且安全的方案是Https + token + url签名。
- https用来保证链路的安全，避免数据被截取
- token是用来签权的，看是否是合法的用户
- url签名是把请求参数做一个不可逆的算法签名，作用一是保证内容没有被篡改，作用二是也保证了客户端的合法性，因为算法是和后台约定的
有些公司会使用时间戳校验，如果时间相差超过一定时间就认为无效，这种做法还有待商榷，因为有可能用户的时间是手动调过的，就不能以用户手机的时间为准了，如果用服务器时间就需要经常请求，也不合适，那就需要一套用户和服务器时间同步机制了，个人认为不是很必要。
总结
token自校验这种方式更适用于开放平台，类似微信这种，在token中加入信息去校验调用者是否符合要求，同时权限范围也在token中有指定。
查表校验更适用于自家App，有token/sessionId就可以执行此用户的所有操作。
