Cookie、Session、JWT

Cookie

Cookie是一个载体。服务器可以通过响应头 Set-Cookie 给客户端（浏览器）设置 Cookie。浏览器在请求同域网页时会自动携带 Cookie（放在请求头中）。

Session

Session 保持用户登录的方式，类似于和客户端约定暗号。客户端第一次使用用户名密码登录时，服务器通过 Set-Cookie 返回一个暗号（Session ID），自己也存下这个暗号。当后续请求时，不必每次都携带用户名与密码，只要带着这串暗号即可（客户端自动通过 Cookie 携带 Session ID）。
这种方式的缺点如下：

• 每有一个客户端，服务器就需要维护一个 Session ID。当客户端数量增长时，服务器同时维护大量 Session ID
• 为了稳定性，服务器通常会有集群，所以也就涉及多台服务器共享 Session ID，需要处理一致性等数据共享问题

JWT

JWT 保持用户登录的方式，类似服务器保留一个钥匙（JWT 签名密文），向客户端分发锁头（Token）。客户端第一次使用用户名密码登录时，服务器使用自己的钥匙+该用户的用户名+一定的加密方式，通过非对称加密制造一把锁头（Token）。当后续请求时，客户端携带这个锁头即可，通常服务器返回 Token 后，客户端存储在 LocalStorage，在后续通过 Authorization Bearer Token 请求需要鉴权的接口。
这种方式的优点在于：

• 不必使用 Cookie，可以进行跨域请求
• 服务器不需要存储所有客户端的信息，只需要维护一份秘钥。在客户端访问时，只要能够成功使用自己的秘钥解密，就证明是通过认证
• 基于第二点，服务器变成无状态了，更容易进行扩展
• 使用非对称加密，在秘钥没有泄露的情况下，中间人无法自己伪造能被服务器私钥解密的 Token

相比于 Session 的不足之处在于：由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
举个例子，就是一旦你登录成功了，后面改了密码也无法让 token 失效，除非服务器部署额外的逻辑。

JWT 说明

JWT 组成：Header.Payload.Signature。

Header（头部）是一个 JSON 对象，描述 JWT 的元数据，存储签名算法（默认 H256）、类型（JWT）。最后进行 base64Url 编码

Payload（负载）是一个 JSON 对象，存放传递的数据，有一些官方预置可选字段，也可以定义私有字段。最后进行 base64Url 编码

Signature（签名）通过 Header 中的算法进行签名，例如公式：HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

三部分最后用 . 分隔就是返回给用户的 JWT。

JWT Debugger：https://jwt.io/