一文整明白Cookie、Session、Token

Cookies

Cookies是由服务器产生的。

Cookie就是服务器委托浏览器存储在客户端(浏览器)里的一些数据，而这些数据通常都会记录用户的关键识别信息。

浏览器第一次访问服务端时，服务器此时肯定不知道他的身份，所以创建一个独特的身份标识数据，格式为key=value，放入到Set-Cookie字段里，随着响应报文发给浏览器。
浏览器看到有Set-Cookie字段以后就知道这是服务器给的身份标识，于是就保存起来，下次请求时会自动将此key=value值放入到Cookie字段中发给服务端。
服务端收到请求报文后，发现Cookie字段中有值，就能根据此值识别用户的身份然后提供个性化的服务。

Session

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

如果将账户的一些信息都存入Cookie中的话，一旦信息被拦截，那么我们所有的账户信息都会丢失掉。

所以就出现了Session，在一次会话中将重要信息保存在Session中，浏览器只记录 SessionId，一个SessionId对应一次会话请求。

那么Session什么时候过期呢？

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

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

Session的管理是在容器中被管理的，什么是容器呢？

Tomcat、Jetty 等都是容器。

Session是存储在Tomcat的容器中，所以如果后端机器是多台的话，因此多个机器间是无法共享Session的。

此时可以使用Spring提供的分布式Session的解决方案，是将Session放在了Redis中。

创建出来后Session保存在哪呢？

创建出来后Session会被保存到一个ConcurrentHashMap中。

Token

Session是将要验证的信息存储在服务端，并以SessionId和数据进行对应，SessionId由客户端存储，在请求时将SessionId也带过去，因此实现了状态的对应。

而Token是在服务端将用户信息经过Base64Url编码过后传给客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了，这个方法叫做JWT(Json Web Token)。

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

Token的优点：

简洁：可以通过URL，POST参数或者是在HTTP头参数发送，因为数据量小，传输速度也很快。
自包含：由于串包含了用户所需要的信息，避免了多次查询数据库。
跨语言：Token是以Json的形式保存在客户端的，所以JWT是跨语言的。
不需要在服务端保存会话信息，特别适用于分布式微服务。

JWT的结构

实际的JWT大概长下面的这样，它是一个很长的字符串，中间用.分割成三部分。

eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJkeHRlc3QiLCJjcmVhdGVkIjoxNTc3MTUxMjEwNDIxLCJleHAiOjE1NzcxOTQ0MTAsInVzZXJpZCI6IjJmMWZkYTI5MzkyMzQ5NTI4OGQwODk3Yjc2NjNjMTVhIiwianRpIjoiZTFlMDZiYjU5MzExNDFjYmE3M2JiMTczM2ZjZWE2ODIifQ.rOnyuQppNJ0OeZrk4S3TkvqMeYq4EH48qPFq1FVkQlWo2cI_F7vWuKJqmHKEaITYgxJG3z_VjqHMlWsOszU7iA

JWT是由三部分组成的：

Header:

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

{
  "alg": "HS256",
  "typ": "JWT"
}

上面代码中：

alg属性表示签名的算法（algorithm），默认是HMAC SHA256(写成HS256)。

type属性表示这个令牌(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可以使用单个密钥为给定的数据样本创建签名。当消息与签名一起传输时，接收方可以使用相同的密钥来验证签名是否与消息匹配。

总结

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