JWT简介
JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑和自包含的方式，用于在各方之间作为JSON对象安全地传输信息。作为标准，它没有提供技术实现，但是大部分的语言平台都有按照它规定的内容提供了自己的技术实现，所以实际在用的时候，只要根据自己当前项目的技术平台，到官网上选用合适的实现库即可
网址：https://jwt.io/
JWT串如一下所示：
JWT的数据结构以及签发过程
JWT由3个部分组成，用.分隔
* Header
* Payload
* Signature
JWT通常如下所示
xxxxx.yyyyy.zzzzz
1、Header
第一部分是请求头由两部分组成，alg与typ,第一个指定的是算法，第二指定的是类型。
例如：
{
"alg": "HS256",
"typ": "JWT" }
typ：用来标识整个token字符串是一个JWT字符串
alg：用来说明这个JWT签发的时候所使用的签名和摘要算法
常用的值以及对应的算法如下：
一般签发JWT的时候，header对应的json结构只需要typ和alg属性就够了。JWT的header部分是把前面的json结构，经过Base64Url编码之后生成出来的
2、Payload
第二部分是主体信息组成,用来存储JWT基本信息，或者是我们的信息。
例如：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true }
payload的json结构并不像header那么简单，payload用来承载要传递的数据，它的json结构实际上是对JWT要传递的数据的一组声明，这些声明被JWT标准称为claims，它的一个“属性值对”其实就是一个claim，每一个claim的都代表特定的含义和作用。比如上面结构中的sub代表这个token的所有人，存储的是所有人的ID；name表示这个所有人的名字；admin表示所有人是否管理员的角色。当后面对JWT进行验证的时候，这些claim都能发挥特定的作用。
根据JWT的标准，这些claims可以分为以下三种类型：
a. Reserved claims（保留），它的含义就像是编程语言的保留字一样，属于JWT标准里面规定的一些claim。JWT标准里面定好的claim有：
iss(Issuser)：代表这个JWT的签发主体；
sub(Subject)：代表这个JWT的主体，即它的所有人；
aud(Audience)：代表这个JWT的接收对象；
exp(Expiration time)：是一个时间戳，代表这个JWT的过期时间；
nbf(Not Before)：是一个时间戳，代表这个JWT生效的开始时间，意味着在这个时间之前验证JWT是会失败的；
iat(Issued at)：是一个时间戳，代表这个JWT的签发时间；
jti(JWT ID)：是JWT的唯一标识。
b. Public claims，略（不重要）
c. Private claims，这个指的就是自定义的claim。比如前面那个结构举例中的admin和name都属于自定的claim。这些claim跟JWT标准规定的claim区别在于：JWT规定的claim，JWT的接收方在拿到JWT之后，都知道怎么对这些标准的claim进行验证；而private claims不会验证，除非明确告诉接收方要对这些claim进行验证以及规则才行。
按照JWT标准的说明：保留的claims都是可选的，在生成payload不强制用上面的那些claim，你可以完全按照自己的想法来定义payload的结构，不过这样搞根本没必要：第一是，如果把JWT用于认证， 那么JWT标准内规定的几个claim就足够用了，甚至只需要其中一两个就可以了，假如想往JWT里多存一些用户业务信息，比如角色和用户名等，这倒是用自定义的claim来添加；第二是，JWT标准里面针对它自己规定的claim都提供了有详细的验证规则描述，每个实现库都会参照这个描述来提供JWT的验证实现，所以如果是自定义的claim名称，那么你用到的实现库就不会主动去验证这些claim
最后也是把这个json结构做base64url编码之后，就能生成payload部分的串：
3、Signature
第三部分主要是给第一部分跟第二部进行签名使用的,用来验证是否是我们服务器发起的Token，secret是我们的密钥。
下面例子使用HMAC SHA256算法进行签名
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
正好找到一个在线工具能够测试这个签名算法的结果，比如我们拿前面的header和payload串来测试，并把“secret”这个字符串就当成密钥来测试：
最后的结果B其实就是JWT需要的signature。不过对比我在介绍JWT的开始部分给出的JWT的举例：
会发现通过在线工具生成的header与payload都与这个举例中的对应部分相同，但是通过在线工具生成的signature与上面图中的signature有细微区别，在于最后是否有“=”字符。这个区别产生的原因在于上图中的JWT是通过JWT的实现库签发的JWT，这些实现库最后编码的时候都用的是base64url编码，而前面那些在线工具都是bas64编码，这两种编码方式不完全相同，导致编码结果有区别。
以上就是一个JWT包含的全部内容以及它的签发过程。接下来看看该如何去验证一个JWT是否为一个有效的JWT。
JWT的验证过程
这个部分介绍JWT的验证规则，主要包括签名验证和payload里面各个标准claim的验证逻辑介绍。只有验证成功的JWT，才能当做有效的凭证来使用。
先说签名验证。当接收方接收到一个JWT的时候，首先要对这个JWT的完整性进行验证，这个就是签名认证。它验证的方法其实很简单，只要把header做base64url解码，就能知道JWT用的什么算法做的签名，然后用这个算法，再次用同样的逻辑对header和payload做一次签名，并比较这个签名是否与JWT本身包含的第三个部分的串是否完全相同，只要不同，就可以认为这个JWT是一个被篡改过的串，自然就属于验证失败了。接收方生成签名的时候必须使用跟JWT发送方相同的密钥，意味着要做好密钥的安全传递或共享。
再来看payload的claim验证，拿前面标准的claim来一一说明：
iss(Issuser)：如果签发的时候这个claim的值是“a.com”，验证的时候如果这个claim的值不是“a.com”就属于验证失败；
sub(Subject)：如果签发的时候这个claim的值是“liuyunzhuge”，验证的时候如果这个claim的值不是“liuyunzhuge”就属于验证失败；
aud(Audience)：如果签发的时候这个claim的值是“['b.com','c.com']”，验证的时候这个claim的值至少要包含b.com，c.com的其中一个才能验证通过；
exp(Expiration time)：如果验证的时候超过了这个claim指定的时间，就属于验证失败；
nbf(Not Before)：如果验证的时候小于这个claim指定的时间，就属于验证失败；
iat(Issued at)：它可以用来做一些maxAge之类的验证，假如验证时间与这个claim指定的时间相差的时间大于通过maxAge指定的一个值，就属于验证失败；
jti(JWT ID)：如果签发的时候这个claim的值是“1”，验证的时候如果这个claim的值不是“1”就属于验证失败
需要注意的是，在验证一个JWT的时候，签名认证是每个实现库都会自动做的，但是payload的认证是由使用者来决定的。因为JWT里面可能不会包含任何一个标准的claim，所以它不会自动去验证这些claim。
以登录认证来说，在签发JWT的时候，完全可以只用sub跟exp两个claim，用sub存储用户的id，用exp存储它本次登录之后的过期时间，然后在验证的时候仅验证exp这个claim，以实现会话的有效期管理。
JWT 令牌注销或者销毁
痛点：当用户点击了“注销”按钮，用户的令牌在Angular端会从授权认证服务AuthenticationService中移除，但是此令牌仍旧是有效的，还可以被攻击者窃取到，用于API调用，直至jsonwebtoken的有效时间结束
解决方案：利用Redis撤销JSON Web Token产生的令牌，当用户点击注销按钮时。且令牌在Redis存储的时间与令牌在jsonwebtoken中定义的有效时间相同。当有效时间到了后，令牌会自动被Redis删除。最后，创建Node.js应用来检查各终端上传的令牌在Redis中是否存在。
DEMO
客户端发起请求
服务器端获取Token
验证Token
设置跨域（略）
参考：
https://github.com/jwtk/jjwt
https://www.cnblogs.com/lyzg/p/6028341.html