session ,cookies，token三者的区别以及作用场景

session ,cookies，token三者的区别以及作用场景

场景描述

fjh到健身房去练胸肌，首先领了钥匙，然后进了更衣间，把衣服，裤子，手机，钱包都放在盒子里面。

plw也到健身房，去练翘臀。首先领了钥匙，然后 进了更衣间，把衣服，裤子，手机，《Java 21天从入门到精通》也放在了一个盒子里，但是这个盒子是和fjh的是不同的。

健身房，就相当于服务器，盒子，就是会话Session。

切换到我们常见的购物网站的场景
plw登陆天猫之后，在购物车里看到的物品是蜡烛和皮鞭
fjh登陆天猫之后，在购物车里看到的物品是手铐和《Java 21天从入门到精通》

fjh和plw都有自己的盒子，那么他们怎么知道哪个盒子是自己的呢？
通过钥匙就能找到自己的盒子了。

盒子对应服务器上的Session。
钥匙对应浏览器上的Cookie

可这只能在健身房用啊，怎样能做到跨健身房也能验证打开盒子呢？

今天是9102年了，盒子存放东西被人们摒弃了，出现了一门高科技，因为出现了有人伪造钥匙偷走了东西，放在健身房的东西在家也能看到，用手机人脸识别就可打开应用并进行相应操作，并且只有本人才能看到盒子的东西；

家相当于另一个服务器，人脸识别技术相当于token认证；

token可以抵抗csrf，cookie+session不行

假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。

分布式情况下的session和token

我们已经知道session是有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。

• 负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session。这个问题也可以将session存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。当今的几种解决session负载均衡的方法。

而token是无状态的，token字符串里就保存了所有的用户信息

• 客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)

token认证流程

token 的认证流程与cookie很相似

• 用户登录，成功后服务器返回Token给客户端。
• 客户端收到数据后保存在客户端
• 客户端再次访问服务器，将token放入headers中
• 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

最后

• session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。
• cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。
• token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。
  似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。
• jwt只是一个跨域认证的方案