JWT学习

1.JWT介绍

授权系统会做很多操作，包括登陆，校验等，所以需要的资源比较多，可能会出现系统瓶颈的问题，现在一般流行简化的方式，如果我们的AB服务自己知道如何校验的话，就不需要去授权系统进行请求校验了，而是自己直接校验就可以了，但是如果校验的安全级别不够的话比较容易被人伪造信息，这里就可以使用我们上面的签名的方式来提高安全度，那可不可以这样呢，我们的授权系统将授权信息签名后发给客户，客户下次带着数据过来，我们进行签名校验就可以了，如果可以，说明没有问题，这种技术我们称之为令牌Token

Json Web Token (JWT） 是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。
一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。
头部（Header）
头部用于描述关于该JWT的最基本的信息，例如器类型以及签名所用的算法等。这也可以被表示成一个JSON对象。
{“typ”:“JWT”,“alg”:“HS256”}
在头部指明了签名算法是HS256算法。我们进行BASE64编码http://base64.xpcha.com/,编码后的字符串如下:

载荷(playload)
载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分
(1) 标准中注册的声明(建议但不强制使用)

(2) 公共的声明
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息。但不建议添加敏感信息，因为该部分在客户端可解密。
(3) 私有的声明
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
这个指的就是自定义的claim。比如前面那个结构举例中的admin和name都属于自定的claim。这些claim跟JWT标准规定的claim区别在于: JWT规定的claim,JWT的接收方在拿到JWT之后，都知道怎么对这些标准的claim进行验证(还不知道是否能够验证); 而private claims不会验证，除非明确告诉接收方要对这些告诉接收方要对这些claim进行验证以及规则才行。
定义一个payload:

然后将其进行base64解密，得到JWT的第二部分

签证(signature)
jwt的第三部分是一个签证信息，这个签证信息有三部分组成:

• header(base64后的)
• payload(base64后的)
• secret

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中的声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

注意: secret是保存在服务器端，jwt的签发生成也是放在服务器端的，secret就是用来进行jwt的签发和Jwt的验证，所以，他就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret,那就意味着客户端是可以自我签发Jwt了。