JWT结构详解

1、 JWT概念和作用

JWT全称为json web token，说白了是什么呢？就仅仅只是一个字符串而已，例如：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0.OLvs36KmqB9cmsUrMpUutfhV52_iSz4bQMYJjkI_TLQ 这样。

2、JWT组成

JWT包含了三个主要部分：Header.Payload.Signature，以" . "来进行分割，以上式举例： eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0. OLvs36KmqB9cmsUrMpUutfhV52_iSz4bQMYJjkI_TLQ

注意尾巴上的两个点哦。

2.1 Header作用

Header部分主要存储关于签名算法的信息，通常包含两个部分：token类型和采用的加密算法，大致源内容如下： { “alg”: “HS256”, “typ”: “JWT”} ，然后使用Base64Url编码组成了Header部分，结果大致如：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。

2.2 Payload作用

Payload翻译过来就是负载嘛，就是装东西嘛对不对，所以这一部分其实是用来存储一些信息的，至于是什么信息呢，重点来了 ----> 无所谓，惊不惊喜，意不意外？

其实Payload是一个比较重要的部分，这个东西其实就是一个数据实体，俗称Claim，JWT并不强制使用，它默认这一部分数据为业务数据，是系统业务需要的数据，可有可无，可多可少。一般在不特殊修改的情况下，主要包含几个部分：iss（签发者）,exp（过期时间戳）, sub（面向的用户）, aud（接收方）, iat（签发时间），大致的源样式是这样： { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true}，经过Base64Url 编码以后，会变成JWT的第二部分字符串：eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0。

2.3 Signature作用

创建签名需要使用编码后的header和payload以及一个秘钥，组成的公式：编码后的header、编码后的payload、一个secret进行加密HMACSHA256( base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

以上就是JWT的几个主要组成部分。

3、JWT的主要作用

JWT最开始的初衷是为了实现授权和身份认证作用的，可以实现无状态、分布式的Web应用授权，大致实现的流程如下：

JWT的使用流程大致有几步： 1、客户端需要携带用户名/密码等可证明身份的内容去授权服务器获取JWT信息；

2、每次服务都携带该Token内容与Web服务器进行交互，由业务服务器来来验证Token是否是授权系统发放的有效Token，来验证当前业务是否请求是否合法。

注意：这里很多刚接触JWT的童鞋经常会问一个问题，是不是每次请求都申请一次Token，这里需要注意，如果不是对于安全性要求非常高的情况，不建议每次请求都申请，因为会增加业务耗时，大部分时候我个人喜欢在登陆时申请，然后使用JWT的过期时间或其他手段来保障JWT的有效性

后来随着JWT使用的场景的成熟，逐渐引申的意义也可以抵御跨站请求伪造攻击和签名验签的流程。

a）如何保证JWT的安全呢？

注意，这里经常会有一个误区，JWT本身和安全没关系，它就仅仅只是一个字符串，使用它来做安全远不如类似于RSA2这样的非对称加密的形式来的实在，由于客户端的程序对用户几乎完全透明，验签的过程对于他们来讲也是透明的，所以安全性肯定不会靠这个来实现，如果实在怕JWT的被盗取，可以考虑在Payload部分加入一些客户端独有的非敏感信息，用于在服务端来进行核验，比如使用MAC-Message Authentication Code、或者公钥之类的等等; 或者干脆就把生效时间设置的短一些，也可以减少暴漏的风险。

b）要不要将用户信息存入Payload呢

其实是一个道理，由于JWT本身没有安全性可言，所以存储用户信息，尤其是敏感数据是一件很可怕的事情，建议不要存放这一类信息；而且将太多的信息存入Payload以后，就增加了网络传输以及签名和验签的复杂度，也会造成时间的浪费；

c）如果想上传视频，如何使用JWT进行签名呢

这件事要分两头说，JWT签名对我个人而言，并不是所有数据都要签名，因为会增加业务耗时和复杂度，所以我一般都是对一些敏感数据才会进行签名。基于以上基点，不难分析出这个问题的答案： 1、如果视频并不算敏感数据，那么自然就不存在签名问题 2、如果确实认为视频是敏感数据，可以通过nodejs之类的东东获取到上传文件的对象，然后进行操作，当然，这是一个非常复杂的工作，要有心理准备哦。 3、这个问题其实仅仅只是一个例子，所有类似的问题处理方法差不多，只要意识到什么数据应该签名，什么数据可以不签名，其他都是一些技术细节，这里就不讨论了。