Cookie、Session、Token、JWT之间的关系

首先，提出一个问题：服务器是如何区分用户的？

首先浏览器会进行登录，将用户名和密码发送给服务器，服务器查询后就知道是哪个用户的请求了。

但是之后的请求呢？也每次都带上账号密码向服务器进行请求吗？

当然可以，但是这不安全，很容易导致敏感信息的泄露。这样的操作需要客户端保存这些信息。

那么怎么样做才能保障信息的安全呢？

通常是服务器返回一些标志信息，浏览器收到后，将这些信息保存起来以后每次请求都带上，服务器就可以根据这些标志信息来区分用户了，就可以成功实现记住登陆状态了，这就是Cookie。

Cookie的保存和发送是由浏览器自动实现的，不需要网页代码格外处理。

但是此时的Cookie信息是有问题，Cookie里面的信息很容易被有坏心思的人猜到，用同样的格式向服务器请求，拿到同样的权限，所以我们还需要加上一些手段，来防止Cookie信息被冒用，被人恶意篡改。我们可以使用数据签名的方式来避免这种情况。签名随着数据一同发给浏览器作为Cookie，这样后面的请求服务器就可以通过签名来判断数据是否合法了。这样的签名是很难伪造的，因为签名通常会带上服务器的密令。

有些时候，我们不想要浏览器Cookie保存太多的数据，那么我们可以将数据保存在服务端，并且生成一个足够长的随机KEY来与数据做关联，然后把KEY返回给浏览器并且写入Cookie，这样下次请求的时候，服务器就可以根据KEY来找到相对应的数据了。这种过程就是Session了。KEY就是SeesionID，Session的本质还是Cookie，唯一不同的是只给了浏览器一个SessionID作为唯一身份。会话的数据全部保存在服务器里面，由服务器管理。

但是在我们的移动互联网中，我们的终端除了网页，还有APP和小程序等。这些客户端的网络请求接口默认是没有Cookie机制的。那么我们应该怎么办呢？

客户端程序将"SessionID"在存储系统里保存起来，SessionID换个名字就叫做Token。Token和Session还是一样的，只是少了浏览器的Cookie机制，需要自己维护。当然为了遵循Bearer认证规范，客户端请求时不再使用Cookie字段，而是Authorization字段。到这里你会发现，我们的Session和Token的会话数据都是放在服务器里面的，在单机服务器里面没有问题，但是在分布式服务器下就会出现某些问题，比如某些服务器没有会话数据，导致鉴权失败。通常为了解决这种情况，我们会在服务器端再架设一个中心化的存储服务列如Redis来专门存储会话数据。但是中心化的服务会给分布式系统造成性能瓶颈，而且一旦中心化服务出现故障，就会造成所有服务器故障。

所以我们还是希望会话数据交给客户端管理，接口尽可能是无状态的。那也好办，我们直接把Cookie的数据搬过来作为Token就好了。但是这个Cookie的签名算法不统一，所以我们需要一个标准，JWT就是其中的一种标准，JWT其中生成的Token由三部分组成，第一部分头部包含Hash算法以及Token类型，第二部分载体包含需要携带的会话数据，第三部分则是签名，签名与Cookie签名类似，这样生成的Token，一来可以携带数据，二来可以作为凭证，更规范，解析新能更好。但是需要注意的是，JTW并不安全，任何人都可以解开，所以注意和Cookie一样，敏感的信息不要放在JWT中。