很多童鞋在课程中会问到一些与JWT相关的内容，在这里算是给大家简单聊一聊，不过在这里要提前说一下，由于JWT在不同的人和不同的项目中使用的方式都会有一些区别，这里仅仅代表个人见解。

一、JWT简介【对于了解JWT的童鞋，可以直接跳到最后】

咱们就不弄那些乱七八糟的概念，就简单点说一下JWT是什么、有什么和能干什么

1、 JWT概念和作用

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9obiBEb2UiLCJhZG1pbiI6dHJ1ZX0.OLvs36KmqB9cmsUrMpUutfhV52_iSz4bQMYJjkI_TLQ 这样。

O(∩_∩)O 是不是特别长，特别丑？没关系，现在给大家解释一下这个东东到底是什么

2、JWT组成【对于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、这个问题其实仅仅只是一个例子，所有类似的问题处理方法差不多，只要意识到什么数据应该签名，什么数据可以不签名，其他都是一些技术细节，这里就不讨论了。

欢迎关注课程《Tomcat+Memcached/Redis集群 构建高可用解决方案 》