什么是JWT?

JWT是JSON Web Token的缩写，它是一种开源标准(RFC 7519)，用来定义通信双方如何安全地交换信息的格式。

本身定义比较简单，结合实践经验，我总结了几点能够更好地帮助理解什么是JWT。

重点：

• JWT之所以叫JSON Web Token，是因为其头部和载荷在编码之前都是JSON格式的数据；
• JWT是一种标准，它有很多的实现方案，比如jwt-auth，专门为php框架laravel打造，java玩家可以看下java-jwt；

• JWT规定以JSON的格式传递信息，负载payload的数据格式是JSON的，通常使用base64编码；
• JWT是自包含的，Token本身携带了验证信息，不需要借助其他工具就可以知道一个Token是否有效，以及载荷信息；
• JWT的某些实现比如黑名单机制、Token刷新等增强功能，可能也需要借助其他工具，但是这并不违背自包含特性。

JWT的结构

上图可以直观的看出JWT的结构，三种颜色代表三个部分，头部、载荷、签名。

头部

头部本身是JSON格式的，注意这里说的是编码之前的格式。头部包括两个字段，token的类型和加密算法。注意这里说的加密算法是签名的加密算法，不是头部的加密算法，也不是载荷的加密算法。实际上头部并没有经过加密，只是通过base64编码成字符串。

载荷

载荷也是JSON格式的，经过base64编码成字符串。上图例子中可以看到有sub,name,iat三个字段，实际上你可以放更多的信息，只要你需要，前提是JSON格式。

下面这些字段是标准定一个的字段，用来确保jwt有效工作的。

• iss

Issuer的简写，代表token的颁发者。

• sub

Subject的简写，代表token的主题。

• aud

Audience的简写，代表token的接收目标。

• exp

Expiration Time的简写，代表token的过期时间，时间戳格式。

• nbf

Not Before的简写，代表token在这个时间之前不能被处理，主要是纠正服务器时间偏差。

• iat

Issued At的简写，代表token的颁发时间。

• jti

JWT ID的简写，代表token的id，通常当不同用户认证的时候，他们的token的jti是不同的。

以上字段都是RFC 7519标准确定的字段，通常由具体的实现框架来处理，具体的使用者不需要关心。

注意，除了以上标准定义的字段，用户可以自由添加需要的信息，通常我们会把全局的、经常使用的、安全要求不高的信息写入载荷，比如用户ID、用户名等信息。

JWT认证流程

1. 用户使用账号和密码登录，调用后端登录接口；
2. 后端登录程序生成jwt(注意这里小写指的是具体的token)，这一步通常是由jwt插件完成的，我们只需要配置jwt加密密钥、token刷新时间、token有效时间；
3. 后端返回jwt给前端；
4. 前端之后的请求直接带上token即可，只要在token的有效期内；
5. 后端收到前端的请求，会验证token的合法性、有效性，验证通过之后处理请求；
6. 后端发送响应给前端。

JWT常见误区

• JWT是不安全的，因为使用base64编码。这种理解是错误的，头部和载荷确实使用了base64编码，作用是编码而非加密，就是这么设计的，便于前端解码获取信息，所以头部和载荷不要存放保密信息。
• JWT是自包含，不需要借助数据库和缓存。这种理解是错误的，当需要高级功能，比如token刷新、黑名单、多人共享账号等，还是需要借助缓存和数据库。
• 获取头部和载荷信息之后可以修改或者伪造token。这是不可能的，即使头部和载荷的信息完全一样，但是加密的私钥不对，签名也是不对的，后端验证也没法通过。