前言
最近因为各种原因频繁提到 Cookie、Session、Token 是如何记录用户登录态的，所以，今天就略微总结一下这三者在这个场景下的应用。
Cookie
我想作为一个前端，对上述的三者中，最熟悉的就是 Cookie 了。因为前端可以自己操作 Cookie，然后实现自己想要的需求。不过，在很多时候，千万注意不要用 Cookie 存储一些隐私信息，因为一旦被 XSS （脚本注入）就 JJ。
回到正题，Cookie 在需要记录用户登录态的场景下，并不是前端直接存储用户信息，而是在第一次请求登录时，后端将这个用户的信息存储在 Cookie 中（可以设置有效时间、域名等等），并且在响应头中一起发送给前端，然后前端在之后的请求中，都会在请求报文中携带这个 Cookie （携带的过程，是浏览器自动判断后端是否在响应报文中存在 Set-Cookie，存在则同样会在之后的请求报文中携带 Set-Cookie），所以之后，服务端判断是否存在这个 Cookie ，存在则直接读取响应的用户信息，不存在则进行登录操作。从而，完成整个的登录状态的记录。
PS：需要注意的是，后端在 Set-Cookie 的时候，一定要设置这个 Cookie 为 http-only，即这个 Cookie 只能被 http 协议读取，禁止前端以任何方式读取。
Session
对于 Session 这个名称，如果没有了解过的同学可能会一脸懵。相比较 Cookie 是存储在客户端不同的是，Session 是存储在后端的，具体的存储方式，Session 一般是在 Tomcat、Jetty 等容器中进行管理。
同样是记录用户登录态，Session 也会用到 Cookie。不过不同于 Cookie 的是，以 Session 的方式记录用户登录态，会将 用户的信息存储在 Session 中，并且会将 SessionId 塞到 Cookie 中，这个 Cookie 同样会出现在响应报文中（同样需要设置 http-only），之后发生的就和 Cookie 记录登录态的过程类似，只不过读取用户信息是根据 SessionId 来读取对应的 Session 中的用户信息。
Token
以 Token 形式记录登录态和 Cookie 记录登录态有点类似，但是不同的是，Token 并不是直接存储用户信息，而是将用户信息编码后，通过响应报文传给前端，之后每一次请求，请求报文中都会带有这段编码信息，后端通过解码获得用户信息，这个方法也被称作 JWT（Json Web Token）。（所以 Token 适合分布式微服务，即服务端不需要保存特定的用户信息）
值得一提的是 JWT 是由三个部分组成：
1.Header，通常是一个 JSON 对象，用于描述 JWT ，例如
{
"alg": "HS256",
"typ": "JWT"
}
alg 属性代表进行加密的签名的算法，默认是 HS256；type 代表这个令牌的类别。
2.Payload，是用于存放实际需要传输的数据，JWT 官方规定的字段如下：
iss: 签发人
exp：过期时间
sub：主题
aud：受众
nbf：生效时间
iat：签发时间
jti：编号
大家可能会发现，没有我们实际需要的特定字段，JWT 也允许我们自定一些字段（例如用户名之类的）。
3.Signature，是用于对前面的两部分的数据进行签名，防止数据篡改。由服务端定义生成一个秘钥，然后将这三个部分进行签名算法加密，每个部分通过 . 连接成一个字符串，通过响应报文发送给客户端。
