本身定义比较大略，结合实践履历，我总结了几点能够更好地帮助理解什么是JWT。

重点：

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

jwt-auth

phpjwt深刻浅出之JWTJSON Web Token NoSQL

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认证流程

用户利用账号和密码登录，调用后端登录接口；后端登录程序天生jwt(把稳这里小写指的是详细的token)，这一步常日是由jwt插件完成的，我们只须要配置jwt加密密钥、token刷新韶光、token有效韶光；后端返回jwt给前端；前端之后的要求直接带上token即可，只要在token的有效期内；后端收到前真个要求，会验证token的合法性、有效性，验证通过之后处理要求；后端发送相应给前端。
JWT常见误区JWT是不屈安的，由于利用base64编码。
这种理解是缺点的，头部和载荷确实利用了base64编码，浸染是编码而非加密，便是这么设计的，便于前端解码获取信息，以是头部和载荷不要存放保密信息。
JWT是自包含，不须要借助数据库和缓存。
这种理解是缺点的，当须要高等功能，比如token刷新、黑名单、多人共享账号等，还是须要借助缓存和数据库。
获取头部和载荷信息之后可以修正或者假造token。
这是不可能的，纵然头部和载荷的信息完备一样，但是加密的私钥不对，署名也是不对的，后端验证也没法通过。