Web服务的用户验证：从session(cookie)到token

　　之前的工作中用过session和JWT token，为什么用，各有什么特点，一直是个问号，今天简单查阅后记录一下，只说思路，不涉及技术细节。

 

无状态的HTTP与需要状态的用户验证

　　服务端接收到每个HTTP请求时是无状态的，这里的无状态是指不知道多个请求之间有什么关联，就像一个脸盲的人，熟人来了也要问“你是谁”。业务的需求（如购物网站等）导致服务端在接收到HTTP请求时需要知道是哪个用户。解决的思路很简单，就是让用户在登录后，服务端给客户发一个临时“身份证”，以后每次发HTTP请求都带上这个“身份证”，服务端收到请求后验一下就知道是谁了。Session和Token机制都是这个思路。

 

Session与Token

　　session与token都是一种临时“身份证”，不同在于服务端的验证机制。

　　session出现的早，验证过程为：服务端在生成session_id的时候会连同附带信息保存起来，等到验证时，用客户发来的session_id去存储中查询，用查询结果来完成验证。这样的过程缺点很明显：

（1）需要读I/O（数据库或缓存），慢；

（2）当服务端水平扩展时，若同一用户的多个请求被路由到不同的实例中去，则多个实例之间需要session互相拷贝，增加技术复杂度。　　

 

 　　token的验证则采用计算的方式，特点是：用CPU的算力换取了读I/O的时间，也没有了水平扩展时的复杂度。token与session_id的不同在于：token分为两个部分，前一部分包含用户、时效等信息，后一部分则是一个签名（一段字符串），由加密算法把前一部分信息加密生成，加密的过程需要一个自定义的私钥，这个私钥只存在于服务端，外界不知道。token生成后，发给客户端，等到再次验证时，把客户发来的token拿来，用其中的前一部分再次生成签名，检查生成的签名与token自带的签名（token的后一部分）是否一致即可。

 

后记

　　假如验彩票有session和token两种机制：那么，session机制就是发行彩票的时候，把每张彩票都留个票根，等需要验彩票时，再找到票根一对即可，缺点是找票根需要时间，并且可能有多个兑奖点，而所需的票根可能不在当前兑奖点；而token的机制则是搞一个验票机，彩票过一下验票机就行，且每个兑奖站的验票机都是一个型号，具体的验证机制只有发行机构知道，这样，就比session机制简单多了。