1. 什么是JWT
JWT是由三段信息构成的，将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样:
jwt的头部承载两部分信息：
声明类型，这里是jwt
声明加密的算法 通常直接使用 HMAC SHA256
完整的头部就像下面这样的JSON：
然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.
载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分
标准中注册的声明
公共的声明
私有的声明
标准中注册的声明 (建议但不强制使用) ：
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
定义一个payload:
然后将其进行base64加密，得到Jwt的第二部分。
jwt的第三部分是一个签证信息，这个签证信息由三部分组成：
这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。
将这三部分用.连接成一个完整的字符串,构成了最终的jwt:
一般是在请求头里加入Authorization，并加上Bearer标注：
2. ID Token - JWT
我们来继续前两章（ OAuth2 总结 , 对OpenID Connect的理解 ）的讨论，进入对JWT的理解。先来简单回顾一下OAuth2和OpenID：
OpenID建立在OAuth之上，完成了认证和授权。而认证和授权的结果就体现在这个ID token之上，而这个ID token通常会是JWT。那么为什么会是JWT呢？我们通过以下几点来逐一解释。
JWT RFC 7519 给出了官方定义的一些字段：
当然也不限于此，可以根据自己的需要，添加其他字段。到此，我们可以看出JWT提供了ID token所需要的能力。一个完整的JTW是由三部分组成：Header，Payload，Signature。三者之间由 . 隔开，刚才提到的认证授权的字段就存在于Payload中。
Header中存放的是JTW的元数据，包含签名的算法以及token的类型，如下所示：
Signature部分是对前两部分的签名， 防止数据篡改 。首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。
算出签名以后，把 Header、Payload、Signature三个部分经过base64序列化为三个字符串，再讲三个字符串由 . 为间隔拼接成一个字符串返回给客户端。
ID Token需要有足够的安全性，JWT是如何做到的呢？
刚看到了签名部分，签名的作用只是为了防止数据篡改，而JWT默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。比如认证服务器中使用私钥进行加密，把公钥分发给其他应用服务器，应用服务拿到加密后的token后用公钥解密，获取到JWT，再用签名的秘钥来验证数据是否经过的篡改。
我们来看看还有神马其他备选么？Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)。
JWT vs SAML：JWT基于json，而SAML基于XML，在大小上就有足够的优势，更适用于HTML和HTTP。
JWT vs SWT：在安全性上，SWT只支持对称加密，而JWT和SAML支持公私钥的加密方式。
作为一个mobile developer，也想在这里对比一下原先的简单token模式和SSO中的JWT：
在没有该机制前，我们通常会使用一个随机产生的字符串作为token，认证成功后返回给前端，之后前端的每个请求带上这个token。若后台服务的是个单体应用没有什么问题，请求来了，验证一下token是否有效即可，但当认证服务和其他的应用服务是分离的，怎么做呢？应用服务受到请求，再向认证服务发起一个请求来验证验证token是否合法，是否有权限访问该应用服务。这样做到没有什么问题，只是当服务变多时，比如微服务下，势必会造成认证服务器的压力过大。
在使用该机制后，客户端通过认证服务登录，获得这个JWT，之后其他应用服务自身便可以验证这个token的是否有效，是否有权访问。
看似完美，但也有它自身的问题，我们来看一个场景：权限变更。某用户原先是一个超级管理员，可以访问所有服务，并可进行任意的删除，更改操作，他在这个状态下拿到了JWT。随后，由于权限更改为普通管理员，便不应该具有所有权限，但此时他开始时的JWT被缓存在客户端仍然可用，其他应用服务也并无法知道这个用户的权限已经被更改，后果可想而知了。解决的方式无非是将这个token的有效时间设置的短一些。
3. JWT的定义及其组成
JWT 的定义及其组成
JWT（JSON Web Token） 是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。
一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。
我们先将用户认证的操作描述成一个JSON对象。其中添加了一些其他的信息，帮助今后收到这个JWT的服务器理解这个JWT。
这里面的前6个字段都是由JWT的标准所定义的。
这些定义都可以在标准中找到。
将上面的JSON对象进行base64编码可以得到下面的字符串：
这个字符串我们将它称作JWT的Payload（载荷）。
如果你使用Node.js，可以用Node.js的包base64url来得到这个字符串：
注：Base64是一种编码，也就是说，它是可以被翻译回原来的样子来的。它并不是一种加密过程。
头部（Header）
JWT还需要一个头部，头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象：
在这里，我们说明了这是一个JWT，并且我们所用的签名算法（后面会提到）是HS256算法。
对它也要进行Base64编码，之后的字符串就成了JWT的Header（头部）：
将上面的两个编码后的字符串都用句号.连接在一起（头部在前），就形成了：
最后，我们将上面拼接完的字符串用HS256算法进行加密。在加密的时候，我们还需要提供一个密钥（secret）:
这样就可以得到我们加密后的内容：
这一部分又叫做签名。
最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT：
4. jwt有什么用
JWT是JSON WEB TOKEN的缩写，它是基于 RFC 7519 标准定义的一种可以安全传输的的JSON对象，由于使用了数字签名，所以是可信任和安全的。
JWT token的格式：header.payload.signature
header中用于存放签名的生成算法
{"alg": "HS512"}Copy to clipboardErrorCopiedpayload中用于存放用户名、token的生成时间和过期时间
{"sub":"admin","created":1489079981393,"exp":1489684781}Copy to clipboardErrorCopiedsignature为以header和payload生成的签名，一旦header和payload被篡改，验证将失败
//secret为加密算法的密钥 String signature = HMACSHA512(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)