JWT（json web token），它并不是一个具体的技术实现，而更像是一种标准。
Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准.该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
JWT规定了数据传输的结构，一串完整的JWT由三段落组成，每个段落用英文句号连接（.）连接，他们分别是：Header、Payload、Signature，所以，常规的JWT内容格式是这样的：AAA.BBB.CCC
并且，这一串内容会base64加密；也就是说base64解码就可以看到实际传输的内容。接下来解释一下这些内容都有什么作用。
Header包含加密的方式、type，比如：
然后我们来看BBB代表的Payload：
顾名思义，这里就会包含实际传递的参数内容，比如：
记住，在这里不要传递那些很敏感的数据，因为只要base64解码就可以看到，除非你还额外加密一层。
最后一部分是CCC代表的Signature，当然也是字面意思——签名，base64解码后，是这个样子：
它主要决定了Header、Payload有没有被人篡改；如果内容被篡改，那么这条JWT将会被视为无效。
那么，一串JWT如何发挥它的作用呢？正常来说，每一次请求都像图里这样就传入就可以了。
记住内容前面的“Bearer”是固定的，并且还得多加一个空格做分割。
基本上绝大部分的人都用JWT做登录授权，它相比原先的session、cookie来说，更快更安全，跨域也不再是问题，更关键的是更加优雅~
当然它也可以用来传递数据，只不过我个人觉得做传输不太好用（实际上我想市场也这么觉得），原因几点：
1、如果是公开展示数据的话，我何必先加签才返回呢？
2、如果是私密数据的话，人家base64解码就能看到，不合适吧？即便我把payload内容加密，可这样一来就加密好几次了，我直接用别的加密手段它不香么？
或许是目前的业务需求并没有很契合，童鞋们遇到了可以一起讨论下。
JWT大概是和 .Net Core 一起进入我视野的，它相对轻便、优雅，对服务器基本没依赖，所以我基本所有项目的登录授权都在用它。用它这么久了还没仔细梳理下，所以今天抽时间写一篇。没有翻查什么文献，也没有很高大上的词缀，就是单纯以我的角度阐述我对它的认识。回头再补一篇JWT在.Net Core的实现。
