像博主一样从完全不懂到懵懂的一小步。
为什么要提JWT？
其实一开始看到这个名字我是拒绝的，就好像让一个一直努力码代码的前端新人来拥抱模块化编程一样，
我为什么要知道它，为什么它就那么好？
言归正传，JWT 全称 JSON WEB TOKEN，是一套开放的标准（RFC 7519），它定义了一套简洁的（compact）、自包含的（self-contained）方案，来让我们安全地在客户端和服务器之间传递 JSON 格式的信息。
说白了，就是一种基于 token 的认证方案。
基于token
或许在这个意义上，你需要自行百度了解一些概念:
SPA 单页面应用，RESTful风格API，CRSF，OAuth 2.0
上述提及的概念比较多，但是如果不了解一下就会回到全文最开始的悖论。简而言之，SPA单页面应用对用户体验的较之服务端渲染要好的多，成为前端开发发展的一个重要的趋势，而随之而来的安全方面的考虑则变得尤为重要起来。
目前的SPA单页面应用获取数据大多是通过类AJAX的方式传输的，而且考虑到负载均衡的各方面因素，很难使用原始的服务端section的方式储存各类验证信息。所以基于token的验证方式应运而生。
Token Auth 机制优势
1. 支持跨域
2. 无状态
3. 更适用于移动应用（当客户端是原生应用时，Cookie支持不佳）
4. 安全性更强，可以防范常见的CSRF（跨站请求伪造）
5. 有完善的业界标准（后文将提到的JWT）
其实优势自然还有很多，这里不一一列举，总而言之，Token Auth机制的好处非常多，尤其是在SPA单页面应用上有着无可替代的位置。
JWT的基本概念
说了那么多废话，就是为了主角JWT，作为Token Auth 机制的一种业内标准，JWT这种基于json格式传输数据的验证方式使得其应用场景非常之多（json格式的好处不必多说了哈）。
JWT 由三部分组成：header / payload / signature
三个部分中间用点分隔开，并且都使用 Base64 编码，所以生成的 Token 类似这样：
ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9.ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ.9q2eq8sa374ao2uq9607r6qu6
(内心os:什么鬼，别急，待我一一道来)
1. Header
首先声明一个 JSON 对象，对象里有一个 type 属性，值为 JWT ，以及 alg 属性，值为 HS256，表明最终使用的加密算法是 HS256。
{
"alg": "HS256",
"type": "JWT"
}
2. Payload
Payload 里面是 Token 的具体内容，这部分内容可以自定义，JWT有标准字段，也可以添加其它需要的内容。
标准字段：
iss：Issuer，发行者
sub：Subject，主题
aud：Audience，观众
exp：Expiration time，过期时间
nbf：Not before
iat：Issued at，发行时间
jti：JWT ID
这是一个典型的payload信息，包含了发行者（网站）、过期时间和用户id：
{
"iss": "jianshu.com",
"exp": "1470730182",
"uid": "12345abcde",
}
这部分内容同样要用Base64 编码，生成编码类似如下格式：
ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ==
3. Signature
它由前面在 Header 指定的算法 HS256 加密两个参数构成，第一个参数是经过编码的 Header 与经过编码的 Payload 通过 . 连接之后的字符串，第二个参数是生成的密钥，会由服务器保存。每次服务器接收到 token 之后，也是先解密出用于验证的用户信息以及密钥，再与自己保存的密钥对比是否相同，以此来验证用户的身份。
将Base64编码后的Header和Payload用.连接在一起
ewogICJ0eXAiOiAiSldUIiwKICAiYWxnIjogIkhTMjU2Igp9.ewogImlzcyI6ICJjaGJsb2dzLmNvbSIsCiAiZXhwIjogIjE0NzA3MzAxODIiLAogInVpZCI6ICIxMjM0NWFiY2RlIiwKfQ
接下来，可能会写JWT的工作流程以及如何使用JWT等文章，敬请期待。
文章延伸阅读
