JWT 是目前流行的跨域身份验证解决方案。
这里给大家介绍 JWT 的原理和用法。
跨域身份验证：
Internet 服务无法与用户身份验证分开。
传统模式过程如下：
1. 用户向服务器发送用户名和密码。
2. 验证服务器后，相关数据（如用户角色，登录时间等）将保存在当前会话 (session) 中。
3. 服务器向用户返回 session_id，session 信息都会写入到用户的 Cookie。
4. 用户的每个后续请求都将通过在 Cookie 中取出 session_id 传给服务器。
5. 服务器收到 session_id 并对比之前保存的数据，确认用户的身份。
这种模式最大的问题是，没有分布式架构，无法支持横向扩展。如果使用一个服务器，该模式完全没有问题。但是，如果它是服务器群集或面向服务的跨域体系结构的话，则需要一个统一的 session 数据库库来保存会话数据实现共享，这样负载均衡下的每个服务器才可以正确的验证用户身份。
例如一个实际中常见的单点登陆的需求：站点 A 和站点 B 提供同一公司的相关服务。现在要求用户只需要登录其中一个网站，然后它就会自动登录到另一个网站。怎么做？
一种解决方案是听过持久化 session 数据，写入数据库或文件持久层等。收到请求后，验证服务从持久层请求数据。该解决方案的优点在于架构清晰，而缺点是架构修改比较费劲，整个服务的验证逻辑层都需要重写，工作量相对较大。而且由于依赖于持久层的数据库或者问题系统，会有单点风险，如果持久层失败，整个认证体系都会挂掉。
另外一种灵活的解决方案：通过客户端保存数据，而服务器根本不保存会话数据，每个请求都被发送回服务器。
JWT 就是这种解决方案的代表。
JWT原理：
1.JWT 的原理是在服务器身份验证之后，将生成一个 JSON 对象并发送回用户，如下所示。
{
“UserName”:“zhangsan”,
“Role”:“Admin”,
“Expire”:“2018-12-01 18:00:00”
}
2. 之后，当用户再与服务器通信时，客户在请求中携带 JSON 对象。服务器仅依赖于这个 JSON 对象来标识用户。为了防止用户篡改数据，服务器将在生成对象时添加签名（有关详细信息，请参阅下文）。
服务器不保存任何会话数据，即服务器变为无状态，使其更容易扩展。
JWT数据结构：
典型的，一个 JWT 对象包含三个部分：JWT头 、 有效载荷 和签名。
该对象是一个很长的字符串，字符之间通过 ”.” 分隔符分成三个子串。注意各字串之间也没有换行符，每一个子串表示了一个功能块，总共有以下三个部分：
1. JWT 头
JWT 头部分是一个描述 JWT 元数据的 JSON 对象，通常如下所示。
{
“alg”:“HS256”,
“typ”:“JWT”
}
在上面的代码中，alg 属性表示签名使用的算法，默认为 HMAC SHA256（写为 HS256）；typ 属性表示令牌的类型，JWT 令牌统一写为 JWT。
最后，使用 Base64 URL 算法将上述 JSON 对象转换为字符串保存。
2. 有效载荷
有效载荷部分，是 JWT 的主体内容部分，也是一个 JSON 对象，包含需要传递的数据。JWT 指定七个默认字段供选择。
iss：发行人
exp：到期时间
sub：主题
aud：用户
nbf：在此之前不可用
iat：发布时间
jti：JWT ID 用于标识该 JWT
除以上默认字段外，我们还可以自定义私有字段，如下例：
{
“UserID”:“89757”,
“UserName”:“张三”
}
请注意，默认情况下 JWT 是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。
JSON 对象也使用 Base64 URL 算法转换为字符串保存。
3. 签名哈希
签名哈希部分是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。
首先，需要指定一个密码（secret）。该密码仅仅为保存在服务器中，并且不能向用户公开。然后，使用标头中指定的签名算法（默认情况下为 HMAC SHA256）根据以下公式生成签名。
HMACSHA256(base64UrlEncode(header) +“.”+ base64UrlEncode(payload),secret)
在计算出签名哈希后，JWT 头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用 ”.” 分隔，就构成整个 JWT 对象。
Base64URL算法：
如前所述，JWT 头和有效载荷序列化的算法都用到了 Base64URL。该算法和常见 Base64 算法类似，稍有差别。
作为令牌的 JWT 可以放在 URL 中（例如 api.example/?token=xxx）。Base64 中用到的三个字符是 ”+”，”/“和”=”，由于在 URL 中有特殊含义，因此 Base64URL 中对他们做了替换：”=“去掉，”+“用”-“替换，”/“用”_” 替换，这就是 Base64URL 算法。
JWT用法：
客户端接收服务器返回的 JWT，将其存储在 Cookie 或 localStorage 中。
此后，客户端将在与服务器交互中都会带 JWT。如果将它存储在 Cookie 中，就可以自动发送，但是不会跨域，因此一般是将它放入 HTTP 请求的 Header Authorization 字段中。
当跨域时，也可以将 JWT 被放置于 POST 请求的数据主体中。
JWT问题和趋势：
1、JWT 默认不加密，但可以加密。生成原始令牌后，可以再次对其进行加密。
2、当 JWT 未加密方法时，一些私密数据无法通过 JWT 传输。
3、JWT 不仅可用于认证，还可用于信息交换。善用 JWT 有助于减少服务器请求数据库的次数。
4、*JWT的最大缺点是服务器不保存会话状态*，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦 JWT 签发，在有效期内将会一直有效。
5、JWT 本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT 的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。
6、为了减少盗用和窃取，JWT 不建议使用 HTTP 协议来传输代码，而是使用加密的 HTTPS 协议进行传输。