保留登陆信息方式的演进

简单讲讲三种主流的保存登陆信息的方式

本篇脱离框架，从基本思想上简述多种授权方式的区别。

首先，基于cookie和session的方式

先说一下cookie和session结合的方式（不去说纯cookie，可以被篡改，安全性太差）

• cookie：存储与客户端的缓存，可以设置数据的过期时间，存储在内存中，会被清除。
• session：同样类似于缓存，客户端与服务器的每次会话，都会存在一个session。识别session基于cookie。实现方式大概是：为一个访问者生成session时，给客户端一个id，这个id对应于这个session。

这种实现的逻辑，基本上就是把数据存于服务器。session保存于服务器，客户端无法直接访问。然后给客户端一把钥匙，客户端携带着这个钥匙，带给服务器，服务器拿着这个钥匙从session里找到客户的信息，然后予以认证。

• 优点：简单，方便。目前的大多数框架都对session存在现有的集成与封装。
• 缺点：最大的缺点是，如果大量用户同时保持登陆状态，服务端则需要存储大量session数据，服务器压力较大。

这种方式还存在其他的小问题，例如：服务器重启后，用户登陆信息消失，用户就需要重新登录；在分布式环境下，无法获取登陆信息；
但是也产生了其解决方案：比如说，存数据库的方式。在数据库的用户表留一个字段，需要找用户信息的时候去数据库找用户信息。再者就是通过redis的方式实现，跑一个redis数据服务器，用redis存session。既保证了应用服务器重启数据不消失，也支持了集群环境。
但是，专门找一台服务器存储用户的登陆信息，还是需要耗费大量的服务器资源。并且，如果应用本身并不需要redis，那为了session专门搭建redis服务，单独放一台服务器，也不太合适。所以JWT应需而生。

JWT，无状态登陆信息

• 思路其实跟session+cookie的方式如出一辙，都是客户端带令牌，服务器来负责通过你的令牌读取你的个人信息。但是JWT不需要服务器存储客户端的信息，而是把用户信息加密到令牌上。然后服务器就不存放用户信息了，但是你的令牌必须通过服务器的加密字段才能解密。客户端存放的令牌上保存着用户的信息，以及令牌过期时间等。
• 生活中举例子就是：给你发了一张身份证，身份证上是一个二维码。二维码里是你的身份信息，以及身份证过期时间。但是只有警方才有扫描你二维码的设备，你本人是没有的。在你买火车票，飞机票，以及办理护照的时候，把这个二维码给相应的人员，他们扫码获取到你的个人信息，并验证没过期就为你办理。如果过期了，就要求你去重新办理一张新的二维码身份证。

这种方式解决的最大的问题就是，服务器不需要存储你的个人信息了。在用户量巨大的情况下，这种方式节省了大量的服务器开支（尤其是部分用户的登陆状态需要保持一个月之久，对服务器来说无疑是巨大的资源消耗）。另外，这种方式也更简单，不需要跟redis进行交互，也不需要跟关系型数据库进行交互。服务器唯一要做的事就是，根据你的JWT解密拿取你得个人信息。