JWT

简介

  JWT，全称是Json Web Token， 是一种JSON风格的轻量级的授权和身份认证规范，可实现无状态、分布式的Web应用授权：

JWT 作为一种规范，并没有和某一种语言绑定在一起，常用的Java 实现是GitHub 上的开源项目 jjwt，地址如下：https://github.com/jwtk/jjwt

JWT 数据格式

JWT包含三部分数据：

Header

头部，通常头部有两部分信息：

1. 声明类型，这里是JWT
2. 加密算法，自定义
   我们会对头部进行Base64Url编码（可解码），得到第一部分数据。

Payload

载荷，就是有效数据，在官方文档中(RFC7519)，这里给了7个示例信息：

• iss (issuer)：表示签发人
• exp (expiration time)：表示token过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

这部分也会采用Base64Url编码，得到第二部分数据。

Signature

  签名，是整个数据的认证信息。一般根据前两步的数据，再加上服务的的密钥secret（密钥保存在服务端，不能泄露给客户端），通过Header中配置的加密算法生成。用于验证整个数据完整和可靠性。

生成的数据格式如下图：

  注意，这里的数据通过 . 隔开成了三部分，分别对应前面提到的三部分，另外，这里数据是不换行的，图片换行只是为了展示方便而已。

JWT交互流程

流程图：

步骤：

1. 应用程序或客户端向授权服务器请求授权
2. 获取到授权后，授权服务器会向应用程序返回访问令牌
3. 应用程序使用访问令牌来访问受保护资源（如API）
   因为JWT签发的token中已经包含了用户的身份信息，并且每次请求都会携带，这样服务的就无需保存用户信息，甚至无需去数据库查询，这样就完全符合了RESTful的无状态规范。

JWT存在的问题

  由客户端维护登录状态带来的一些问题在这里依然存在，举例如下：

• 续签问题，这是被很多人诟病的问题之一，传统的cookie+session的方案天然的支持续签，但是jwt由于服务端不保存用户状态，因此很难完美解决续签问题，如果引入redis，虽然可以解决问题，但是jwt也变得不伦不类了。
• 注销问题，由于服务端不再保存用户信息，所以一般可以通过修改secret来实现注销，服务端secret修改后，已经颁发的未过期的token就会认证失败，进而实现注销，不过毕竟没有传统的注销方便。
• 密码重置，密码重置后，原本的token依然可以访问系统，这时候也需要强制修改secret。

基于第2点和第3点，一般建议不同用户取不同secret。