参考文章：https://ninghao.net/blog/2834
http是无状态的，用户每次输入用户名和密码，通过身份验证后，下回这个客户端再发送请求时还需要验证。
一、传统的身份验证的方法 session
解决方法：当用户请求登录的时候，会跟数据库里的用户名和密码进行比较，如果匹配，会在服务器生成一条记录即session，服务器把这条记录里的sessionID包在cookie中发送给客户端，下次这个用户在向服务器方请求时可以带着这个cookie。服务器会验证一下这个cookie里面的信息，看看能否在服务器找到对应的记录，如果可以，说明用户已经通过了身份验证，服务器返回数据给客户端。
session可能存储在内存，磁盘，或者数据库。我们可能在服务端定期的清理过期的session。
二、基于token的身份验证
基于token的身份验证方法，在服务端不需要存储用户的登录记录。大概流程：
1、客户端使用用户名跟密码进行登录。
2、服务端收到请求去服务端数据库里验证用户名和密码。
3、验证成功后，服务端会签发一个token，再把这个token发送给客户端。
4、客户端收到Token以后把它存储起来，可以存放在Cookie里或者LocalStorage里。
5、客户端每次向服务端请求资源的时候都会带上服务器签发的token。
6、服务端收到请求后，然后去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求的数据。
实施token的方法：
JWT：JSON Web Tokens
JWT标准的token有三部分
header（头部）
payLoad（数据）
signature（签名）
中间用点分隔开，并且都使用Base64编码，所以真正的token看起来像这样：
Header
里面包含使用的加密算法。
例：
意思就是JWT用的算法是HS256。上面的内容用base64url的形式编码一下，就会变成这样：
Payload
Payload里面是token的具体内容，这些内容里面有一些是标准的字段，也可以添加其他需要的内容。
iss：Issuer，发行者。
sub：Subject，主题。
aud：Audience，观众。
exp：expiration time，过期时间。
nbf：Not before。
iat：Issued at，发行时间。
jti：JWT ID
例：
使用base64Url编码后就变成了这个样子：
Signature
包括三部分内容：header、payload、secret（密码），对这三部分内容进行加密。如下：
处理完后看起来像这个样子：
最后在服务端生成的Token：
客户端收到这个 Token 以后把它存储下来，下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ，然后进行验证，通过以后就会返回给客户端想要的资源。
token和session的区别：
token和session都是为了身份验证，session一般翻译为会话，而token更多的时候是翻译成令牌。
session服务器会保存一份，可能保存在缓存，文件和数据库里；同样，session和token都会有过期时间一说，都需要去管理过期时间。
token与session的问题是一种时间与空间的博弈问题。session是空间换时间，token是时间换空间。
虽然确实都是“客户端记录，每次访问携带”，但 token 很容易设计为自包含的，也就是说，后端不需要记录什么东西，每次一个无状态请求，每次解密验证，根据服务端的规则可以当场得出合法 /非法的结论。这一切判断依据，除了固化在 CS 两端的一些逻辑之外，整个信息是自包含的。这才是真正的无状态。
而 sessionid ，一般都是一段随机字符串，需要到后端去检索 id 的有效性。万一服务器重启导致内存里的 session 没了呢？万一 redis 服务器挂了呢？
