简介

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

传统session认证存在的问题

用户登陆后，服务端保存用户信息到当前会话里，同时在响应时返回给客户端，让其保存到cookie中，以便下次请求时发送过来验证。
开销大：session一般保存在服务器内存中，一旦用户认证过多，服务器会花很多不必要的开销在维护和验证这个session上。
难拓展：若是在分布式系统中，不得不建立一个统一的session库来实现session共享。可以放到redis集群中，也可以直接持久化到数据库中，但是性能比较低。
不安全：客户端中的cookie被识别后，容易被攻击。

采用JWT的解决方案

采用基于token的鉴权机制，不需要在服务端去保留用户的认证信息或者会话信息。
流程：

  • 用户发送用户名密码来到服务器请求登录
  • 服务器进行验证用户的账号密码是否正确
  • 服务器通过验证后生成一个token，发送给用户
  • 客户端存储token，并在每次请求时附送上这个token值
  • 服务端验证token值，并返回数据。

JWT构成

一个JWT实际上就是一个字符串，它由三部分组成，头部（header）、载荷（payload）与签名（signature）。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

头部（Header）

头部用于描述关于该JWT的最基本的信息，一般来说，组成如下：

  • 声明类型
  • 签名所用的算法
{
	"typ":"JWT",
	"alg":"HS256"
}

然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.

小知识：Base64是一种基于64个可打印字符来表示二进制数据的表示方法。由于2的6次方等于64，所以每6个比特为一个单元，对应某个可打印字符。三个字节有24个比特，对应于4个Base64单元，即3个字节需要用4个可打印字符来表示。JDK 中提供了非常方便的 BASE64Encoder 和 BASE64Decoder，用它们可以非常方便的完成基于 BASE64 的编码和解码

载荷（playload）

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分：标准中注册的声明（建议但不强制使用），公共的声明，私有的声明。

标准中注册的声明
iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
公共的声明

公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.

私有的声明

私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
这个指的就是自定义的claim。比如下面结构举例中的admin和name都属于自定的claim。这些claim跟JWT标准规定的claim区别在于：JWT规定的claim，JWT的接收方在拿到JWT之后，都知道怎么对这些标准的claim进行验证(还不知道是否能够验证)；而private claims不会验证，除非明确告诉接收方要对这些claim进行验证以及规则才行。

{
	"sub":"1234567890",
	"name":"John Doe",
	"admin":true
}

然后将载荷进行base64加密，得到Jwt的第二部分。

签证（signature）

这个部分需要base64加密后的header和base64加密后的payload使用 . 连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

最后将这三部分（头部、载荷、签证）用 . 连接成一个完整的字符串,构成了最终的jwt。

注意事项

  • JWT的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。
  • JWT本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。
  • 为了减少盗用和窃取，JWT不建议使用HTTP协议来传输代码，而是使用加密的HTTPS协议进行传输。