cookie、session和token
三位都可以用来对用户登录信息进行鉴权
# cookie
# 使用流程
前端输入用户名、密码发起登录请求，服务端会进行用户名认证，认证成功后，将用户名存入响应头的set-cookie属性响应到到前端，浏览器接收到set-cookie后会自动保存cookie，然后在后续的请求中带cookie信息，以此来维持用户的登录状态。
# 弊端
- 安全性很低，因为cookie信息存在前端，可以随意进行修改
- 大小限制：4k
- 浏览器设置内可以对cookie进行禁用
因为这些弊端，我们不能完全依赖于cookie来维持用户的登录状态，进而我们就可以使用session
# session
# 使用流程
前端发起登录请求，服务端进行用户认证，认证成功之后会将用户信息存在session中，响应的时候，会在响应头内存入set-cookie属性，把当前sessionID放在这个属性当中，然后前端会在cookie当中存入当前sessionID。然后在后续的请求中都会带上这个cookie信息，服务端通过cookie拿到这个sessionID，来进行认证，从而维持用户的登录状态。
session相对于cookie来说，存储在服务端，相对比较安全，大小也没有限制，而且存储的信息也不仅仅只限与字符串，也可以将整个用户信息对象存入。但session也有一些弊端。
# 弊端
- 占用服务器资源
- 扩展性差：因为服务器可能使用分布式集群，session信息只会存在一台服务器当中，集群之后负载均衡，有可能在下次请求的时候就会到其他服务器当中，就无法进行登录信息认证。
- 依然需要依赖cookie，且受到跨域限制：在现在前后端分离的情况下，有可能一个服务端对应多个前端（PC、H5、小程序、安卓、IOS），每个应用端口不同，就会造成跨域，cookie默认是不允许进行跨域传递的，处理跨域需要服务端进行允许跨域设置，前端可能也需要配置允许跨域传递cookie，就比较麻烦。
因此在集群环境以及前后端分离的架构下，session已经不再使用，因此我们就需要token来进行登录状态认证。
# Token
Token是一个密钥字符串，我们使用JWT来进行加密
# JWT
JWT由三部分组成
- header
header内包含了算法（采用什么算法来进行加密）和token类型
- payload
payload负载数据内主要存储一些用户信息，这些信息进行base64编码就可以得到第二部分字符串
- signature（密钥）
- base64UrlEncode(header)
- base64UrlEncode(payload)
- 私钥
三部分信息进行header内定义的算法进行加密，就得到了第三部分字符串
# 使用流程
前端发起登录请求，将用户信息给到服务端，服务端拿到用户信息，根据JWT加密成密钥字符串响应到前端，前端通过缓存存到本地，在后续的请求中，与后端协商一个请求头字段，并将token房屋请求头当中发送给服务端，服务端就可以解析到用户信息，以及根据signature来对用户进行认证维持登录状态。
