名词解释
- 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就可以执行此用户的所有操作。
网友评论