前端用户登录机制

session
用户状态存服务端

缺点：
1）由于session 维护在服务器，登录的人一多就服务器压力很大
2）单机ok fine；多机信息同步不方便
3）session+cookie 存在 csrf 风险（当然有解决方案）

token
用户信息加密后传给前端，每次请求带上

token 大名鼎鼎的 jwt
json web token令牌

一旦发送出去，登录信息服务端无法强行作废

JWT

首先这个先说这个东西是什么，干什么用的，一句话说：就是这是一种认证机制，让后台知道请求是来自于受信的客户端。

那么从这个角度而言，这个东西跟浏览器的cookie是一个作用，好比我在一个网站登录了，就可以往这个网站发送restful请求，请求的同时会捎带上cookie，后台检查这个cookie发现你是合法的，才响应你的请求。

只不过这里JWT的原理不同，但基本上最顶层的原理还是非常简单：

这个图中有三个主体： user, application server和authentication server

非常常见的一个架构，首先用户需要 通过登录等手段向authentication server发送一个认证请求，authentication会返回给用户一个JWT（这个JWT的具体内容格式是啥后面会说，先理解成一个简单的字符串好了）

此后用户向application server发送的所有请求都要捎带上这个JWT,然后application server会验证这个JWT的合法性，验证通过则说明用户请求时来自合法守信的客户端。

下面简单说一下这个JWT的格式，十分简单，就是一个三部分组成的字符串：

请转到另一篇博客 JWT的认识

最后再解释一下application server如何认证用户发来的JWT是否合法，首先application server 和 authentication server必须要有个约定，例如双方同时知道加密用的secret（这里假设用的就是简单的对称加密算法），那么在applicaition 收到这个JWT是，就可以利用JWT前两段（别忘了JWT是个三段的拼成的字符串哦）数据作为输入，用同一套hash算法和同一个secret自己计算一个签名值，然后把计算出来的签名值和收到的JWT第三段比较，如果相同则认证通过，如果不相同，则认证不通过。就这么简单，当然，上面是假设了这个hash算法是对称加密算法,其实如果用非对称加密算法也是可以的，比方说我就用非对称的算法，那么对应的key就是一对，而非一个，那么一对公钥+私钥可以这样分配：私钥由authentication server保存，公钥由application server保存，application server验证的时候，用公钥解密收到的signature,这样就得到了header和payload的拼接值，用这个拼接值跟前两段比较，相同就验证通过。总之，方法略不同，但大方向完全一样。

一个实战问题:jwt如何实现logout?

一种是设置expire time, 这种可以称为"被动logout",即超过了一定时间自动失效,但是如果等不及,就是想主动logout怎么办呢?由于jwt的这种"无状态"的天然属性,理论上是没有办法直接主动logout的,但是有一个间接的方法,就是可以在服务器后台存一个"黑名单",这个黑名单专门用来存尚未过期但又想主动标明失效的的token,然后登录状态检查的时候多做一步黑名单检查即可.

参考链接：https://blog.csdn.net/xunileida/article/details/82961714