以微信公众号爬虫为例，谈谈对session、cookie和token认证的理解

为什么需要这些认证

我们通过浏览器访问多数网站，本质上都可以理解为客户端（用户）和服务端（网站）之间的一次遵循http协议的请求和应答，比如：把a页面给我（返回a.html），删除b图片（删除b.jpg）。但是http协议本身是无状态的，也就是说我们每一次向网站发送请求，服务器都并不知道我们是谁、是否请求过、有何偏好（共享数据），所以需要一种验证机制将我们的所有请求关联起来。

session和cookie

在http协议之上，通过cookie实现了持久的会话，这个会话便称为session；
session是存储在服务端、用来验证用户身份的状态数据，具有唯一标识sessionId；
cookie是存储在客户端的用户身份数据，浏览器会自动加入服务端提供的sessionId。

验证流程：
1、客户端向服务端发送http请求；
2、服务端接受请求，建立一个session然后向客户端发送应答，其中应答的响应头Set-Cookie中包含sessionId；
3、客户端再次发送请求，如果之前有收到set-Cookie会将Cookie一起提交；
4、服务端再次接受请求，分解Cookie并验证消息，核对成功后发送应答。

验证缺点：
1、由于session保存在服务端，当用户基数很大的时候，为了保证认证效率需要消耗大量内存或缓存；
2、对于分布式系统，如果session一开始保存在A服务端，而客户端的下次请求被服务器负载均衡转发到了B服务端，则没办法通过认证（可以通过session共享来解决，即把所有session保存在一个服务器）；
3、会受到CSRF跨站请求伪造攻击：session和cookie的验证方式只能保证请求来自我们的浏览器，却不能保证请求是我们自愿发出的。假如银行网站使用这种验证方式，在我们验证之后浏览器会暂时保存我们的登录状态，接着我们不小心浏览了包含以下恶意代码’'的钓鱼网站，这时浏览器就会使用我们的账户向银行发送转账申请（CSRF攻击没有直接窃取我们的账户或个人信息，但它利用session验证以我们的名义向网站发送请求）。

token

token也称作令牌，相当于临时证书签名，由uid（用户唯一身份标识）、time（当前时间的时间戳）、sign（签名，使用hash/encrypt压缩的十六进制字符串）和parms（固定参数，可选）组成

验证流程：
1、客户端向服务端发送登录请求；
2、服务端接受请求，验证成功后返回Token；
3、客户端再次发送请求，将之前保存的Token加入header或作为表单一起提交；
4、服务端再次接受请求，验证Token成功后返回应答。
（token一般需要设置有效期，为了避免正常操作时token失效，一种对策是把token失效时间保存在缓存中，用户每操作一次就更新失效时间；另一种对策是token快失效时，通知前端通过refresh token重新申请）

优点
1、token是无状态的，所以只需要在成功的登录请求上对令牌进行签名，并验证传入的令牌是否有效；
2、可以很容易的对应分布式系统或者跨域访问（JWT）；