JSON Web Token

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

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

jwt-auth
JWT规定以JSON的格式传递信息 负载payload的数据格式是JSON
通常使用base64编码

JWT是自包含的 Token本身携带了验证信息
不需要借助其他工具就可以知道一个Token是否有效 以及载荷信息

JWT的某些实现比如黑名单机制 Token刷新等增强功能 可能也需要借助其他工具 但是这并不违背自包含特性

JWT的结构

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

JWT常见误区

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