彻底搞懂Cookie、Session、Token到底是什么

感谢原创
https://mp.weixin.qq.com/s?__biz=MzU4MDg3MzExMA==&mid=2247484183&idx=1&sn=551397289b1f7ff2e618b6640abb249e&chksm=fd517deeca26f4f8052bfbc90aab580a7df35fc5431532fe7a3a36e7e99ee59658ec75355859&mpshare=1&scene=24&srcid=&sharer_sharetime=1585649055240&sharer_shareid=a57e115a24a13ecbaf2ffa29c0f42a00&exportkey=A%2BsmdmFWV0EuxmeRB9mhpeE%3D&pass_ticket=jomRm6N%2FZreK7p5NbcG0L72p9Hcvivs5MugJAUlZm4C8lyXT%2FxlJMG5%2FLmJI1IOi#rd

1、Cookie
2、Session
3、Token
4、总结

先写总结

**
Cookie是存储在客户端的
Session是存储在服务端的，可以理解为一个状态列表。拥有一个唯一会话标识SessionId。可以根据SessionId在服务端查询到存储的信息。
Session会引发一个问题，即后端多台机器时Session共享的问题，解决方案可以使用Spring提供的框架。
Token类似一个令牌，无状态的，服务端所需的信息被Base64编码后放到Token中，服务器可以直接解码出其中的数据。**

													**Cookie**

在了解这三个概念之前我们先要了解HTTP是无状态的Web服务器，什么是无状态呢？就像上面夏洛特烦恼中经典的一幕对话一样，一次对话完成后下一次对话完全不知道上一次对话发生了什么。如果在Web服务器中只是用来管理静态文件还好说，对方是谁并不重要，把文件从磁盘中读取出来发出去即可。但是随着网络的不断发展，比如电商中的购物车只有记住了用户的身份才能够执行接下来的一系列动作。所以此时就需要我们无状态的服务器记住一些事情。

那么Web服务器是如何记住一些事情呢？既然Web服务器记不住东西，那么我们就在外部想办法记住，相当于服务器给每个客户端都贴上了一个小纸条。上面记录了服务器给我们返回的一些信息。然后服务器看到这张小纸条就知道我们是谁了。那么Cookie是谁产生的呢？Cookies是由服务器产生的。接下来我们描述一下Cookie产生的过程

浏览器第一次访问服务端时，服务器此时肯定不知道他的身份，所以创建一个独特的身份标识数据，格式为key=value，放入到Set-Cookie字段里，随着响应报文发给浏览器。

浏览器看到有Set-Cookie字段以后就知道这是服务器给的身份标识，于是就保存起来，下次请求时会自动将此key=value值放入到Cookie字段中发给服务端。

服务端收到请求报文后，发现Cookie字段中有值，就能根据此值识别用户的身份然后提供个性化的服务。

那么浏览器的Cookie是存放在哪呢？如果是使用的是Chrome浏览器的话，那么可以按照下面步骤。

在计算机打开Chrome

在右上角，一次点击更多图标->设置

在底部，点击高级

在隐私设置和安全性下方，点击网站设置

依次点击Cookie->查看所有Cookie和网站数据

然后可以根据域名进行搜索所管理的Cookie数据。所以是浏览器替你管理了Cookie的数据，如果此时你换成了Firefox等其他的浏览器，因为Cookie刚才是存储在Chrome里面的，所以服务器又蒙圈了，不知道你是谁，就会给Firefox再次贴上小纸条。
Cookie中的参数设置
说到这里，应该知道了Cookie就是服务器委托浏览器存储在客户端里的一些数据，而这些数据通常都会记录用户的关键识别信息。所以Cookie需要用一些其他的手段用来保护，防止外泄或者窃取，这些手段就是Cookie的属性。

														**Session**

Cookie是存储在客户端方，Session是存储在服务端方，客户端只存储SessionId

在上面我们了解了什么是Cookie，既然浏览器已经通过Cookie实现了有状态这一需求，那么为什么又来了一个Session呢？这里我们想象一下，如果将账户的一些信息都存入Cookie中的话，一旦信息被拦截，那么我们所有的账户信息都会丢失掉。所以就出现了Session，在一次会话中将重要信息保存在Session中，浏览器只记录SessionId一个SessionId对应一次会话请求。

客户端：和Cookie过期一致，如果没设置，默认是关了浏览器就没了，即再打开浏览器的时候初次请求头中是没有SessionId了。

服务端：服务端的过期是真的过期，即服务器端的Session存储的数据结构多久不可用了，默认是30分钟。

										**Token**

Session是将要验证的信息存储在服务端，并以SessionId和数据进行对应，SessionId由客户端存储，在请求时将SessionId也带过去，因此实现了状态的对应。而Token是在服务端将用户信息经过Base64Url编码过后传给在客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了，这个方法叫做JWT(Json Web Token)。

Token相比较于Session的优点在于，当后端系统有多台时，由于是客户端访问时直接带着数据，因此无需做共享数据的操作。

Token的优点
简洁：可以通过URL,POST参数或者是在HTTP头参数发送，因为数据量小，传输速度也很快

自包含：由于串包含了用户所需要的信息，避免了多次查询数据库

因为Token是以Json的形式保存在客户端的，所以JWT是跨语言的

不需要在服务端保存会话信息，特别适用于分布式微服务
JWT的结构
实际的JWT大概长下面的这样，它是一个很长的字符串，中间用.分割成三部分

JWT是有三部分组成的

Header
是一个Json对象，描述JWT的元数据，通常是下面这样子的

{
  "alg": "HS256",
  "typ": "JWT"
}
```上面代码中，alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。最后，将上面的 JSON 对象使用 Base64URL 算法转成字符串。

> JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

Payload
Payload部分也是一个Json对象，用来存放实际需要传输的数据，JWT官方规定了下面几个官方的字段供选用。

iss (issuer)：签发人

exp (expiration time)：过期时间

sub (subject)：主题

aud (audience)：受众

nbf (Not Before)：生效时间

iat (Issued At)：签发时间

jti (JWT ID)：编号

当然除了官方提供的这几个字段我们也能够自己定义私有字段，下面就是一个例子
 
 {
  "name": "xiaoMing",
  "age": 14
}

在这里插入代码片
默认情况下JWT是不加密的，任何人只要在网上进行Base64解码就可以读到信息，所以一般不要将秘密信息放在这个部分。这个Json对象也要用Base64URL 算法转成字符串

Signature
Signature部分是对前面的两部分的数据进行签名，防止数据篡改。

首先需要定义一个秘钥，这个秘钥只有服务器才知道，不能泄露给用户，然后使用Header中指定的签名算法(默认情况是HMAC SHA256)，算出签名以后将Header、Payload、Signature三部分拼成一个字符串，每个部分用.分割开来，就可以返给用户了。

HS256可以使用单个密钥为给定的数据样本创建签名。当消息与签名一起传输时，接收方可以使用相同的密钥来验证签名是否与消息匹配。