JSON WEB TOKEN

其实在之前都没有听说这个知识点，但是现在 jwt 应该是目前最流行的跨域身份验证解决方案，现在我做的项目中也是使用 jwt，所以想把这个搞懂一下

1. 跨域身份验证

Internet 服务无法与用户身份验证分开，一般过程如下

1. 用户向服务端发送用户名和密码
2. 验证服务器后，相关数据（如用户角色，登录时间等）将保存在当前会话中
3. 服务器向用户返回 session_id，session 信息都会写入到用户的 Cookie
4. 用户的每个后续请求都将通过在 cookie 中取出 session_id 传给服务器。
5. 服务器收到 session_id 并对比之前保存的数据，确认用户的身份

这种模式最大的问题是，没有分布式架构，无法支持很想发展，如果使用一个服务器，该模式完全没有问题。但是如果他是服务器群集活面向服务的跨域体系结构的话，则需要一个统一的 session 数据库来保存会话数据实现共享，这样负载均衡下的每个服务器才可以正确的验证身份。

eg: 常见的单点登陆需求，站点 A 和站点 B 提供同一公司的相关服务。现在要求是用户只需要登陆其中一个网站，然后他就会自动登陆到另一个网站，怎么做？

一种解决方案是持续化 session 数据，写入数据库或文件持久层等，收到请求后，验证服务从持久层请求数据，该解决方案的有点在于架构清晰，但是缺点是架构修改比较麻烦，整个服务的验证逻辑层都需要重写，工作量大，而且由于依赖于持久层的数据库或者问题系统，会有单点风险，如果持久层失败，整个认证体系都会挂掉

2. JWT 原则

jwt 的原则是在服务器生粉验证之后，将生成一个 JSON 对象并将其发送回用户，如下所示：

{
  "UserName": "xuanliao",
  "Role": "admin",
  "Expire": "2019-10-11 11:42:56"
}

之后，当用户于服务器通时，客户在请求中发回 JSON 对象。服务器仅依赖这个 JSON 对象来表示用户，为了防止用户篡改数据，服务器将在生成是添加签名

3. JWT 的数据结构

典型的 jwt 如下图

分为三个部分

1. jwt 头
2. 有效荷载
3. 签名

3.1 JWT 头

JWT 头部分是一个描述 JWT 元数据的 JSON 对象，通常如下所示

{
  "alg": "HS256",
  "typ": "JWT"
}

从上面知道，alg 属性表示签名使用的算法，默认的是 HMAC SHA256（写为 HS256）；typ 属性表示令牌的类型，JWT 令牌统一写为 JWT。

3.2 有效荷载

有效荷载部分是 JWT 的肢体部分，也是 json 对象，包含需要传递的数据。JWT 指定七个默认字段供选择

iss：发行人

exp：到期时间

sub：主题

aud：用户

nbf：在此之前不可用

iat：发布时间

jti：JWT ID 用于标识该 JWT

除了着 7 个值还可以自定义私有字段

{
  "sub": "1234567890",
  "name": "xuanliao",
  "admin": true
}

请注意，默认情况下 JWT 是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。

JSON 对象也使用 Base64 URL 算法转换为字符串保存。

3.3 哈希签名

签名哈希部分是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。

首先，需要指定一个密码（secret）。该密码仅仅为保存在服务器中，并且不能向用户公开。然后，使用标头中指定的签名算法（默认情况下为 HMAC SHA256）根据以下公式生成签名。

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)

在计算出签名哈希后，JWT 头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用"."分隔，就构成整个 JWT 对象。

3.4 Base64URL 算法

如前所述，JWT 头和有效载荷序列化的算法都用到了 Base64URL。该算法和常见 Base64 算法类似，稍有差别。

作为令牌的 JWT 可以放在 URL 中（例如 api.example/?token=xxx）。 Base64 中用的三个字符是"+"，"/"和"="，由于在 URL 中有特殊含义，因此 Base64URL 中对他们做了替换："="去掉，"+"用"-"替换，"/"用"_"替换，这就是 Base64URL 算法，很简单把。

4. JWT 的用法

客户端接收服务器返回的 JWT，将其存储在 Cookie 或 localStorage 中。

此后，客户端将在与服务器交互中都会带 JWT。如果将它存储在 Cookie 中，就可以自动发送，但是不会跨域，因此一般是将它放入 HTTP 请求的 Header Authorization 字段中。

Authorization: Bearer

当跨域时，也可以将 JWT 被放置于 POST 请求的数据主体中。

5. JWT 问题和趋势

1、JWT 默认不加密，但可以加密。生成原始令牌后，可以使用改令牌再次对其进行加密。

2、当 JWT 未加密方法是，一些私密数据无法通过 JWT 传输。

3、JWT 不仅可用于认证，还可用于信息交换。善用 JWT 有助于减少服务器请求数据库的次数。

4、JWT 的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦 JWT 签发，在有效期内将会一直有效。

5、JWT 本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT 的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。

6、为了减少盗用和窃取，JWT 不建议使用 HTTP 协议来传输代码，而是使用加密的 HTTPS 协议进行传输。