JSON Web Token（JWT）是一个开放的标准（RFC 7519），它定义了一个紧凑且自包含的方式，用于在各方之间作为 JSON 对象安全地传输信息。由于此信息是经过数字签名的，因此可以被验证和信任。
今天我们就来简单的认识一下 JSON Web Token。
JWT 认证和 session认证的区别
首先需要说明 JSON Web Token 是可以用于认证的，那么就先来对比一下 JSON Web Token 认证和 传统的 session 认证的区别，传统的 session 认证是有状态的，也就是说我们需要在服务端保存用户的认证信息，如果服务端重新或者换一台服务器，那么这个认证就失效了，并且传统的 session 的认证方式扩展起来不是那么的容易。
基于 JSON Web Token 的鉴权机制类似于 http 协议，是一种无状态的，服务器不需要保存用户的认证信息或者会话信息，这也就意味着 JWT 认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，也是由于这个特性，JWT 在微服务架构中应用广泛。
JSON Web Token 的组成
一个 JSON Web Token 实际上就是一个字符串，它由三部分组成：头部、载荷与签名，如下图所示：
1、头部（header ）
头部用于描述关于该 JSON Web Token 的最基本的信息，例如其类型以及签名所用的算法等，通常如下所示：
{
"alg": "HS256",
"typ": "JWT"
}
- alg属性：表示签名使用的算法，默认为HMAC SHA256（写为HS256）
- typ属性：表示令牌的类型，JWT令牌统一写为JWT
头部一般使用 base64 加密，加密后密文：eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
2、载荷（payload）
载荷是 JSON Web Token 的主体内容部分，里面存放一些有效信息，JSON Web Token 标准定义中定义了以下 5 个字段：
- iss: 该JWT的签发者
- sub: 该JWT所面向的用户
- aud: 接收该JWT的一方
- exp(expires): 什么时候过期，这里是一个Unix时间戳
- iat(issued at): 在什么时候签发的
除了标准定义中的字段外，我们还可以自定义字段，比如在 JWT 中，我们的载荷信息可能如下：
{
"sub": "1234567890",
"name": "pingtouge",
"admin": true
}
我们需要注意，在默认情况下 JWT 是未加密的，每一个人都可以读取其内容，因此在载荷中，不要存放私密信息，防止信息泄露。
3、签名（signature）
签名是 JSON Web Token 中比较重要的一部分，前面两部分都是使用 Base64 进行编码的，signature 需要使用编码后的 header 和 payload 以及我们提供的一个密钥，然后使用 header 中指定的签名算法（HS256）进行签名，签名的作用是保证 JWT 没有被篡改过。
为什么需要签名？
对于加密算法来说，碰撞概率还是比较小的，一般而言，不同的输入加密后的输出是不一样的，不同输入产生相同结果的概率还是相当小的，所以可以利用加密算法的这个特性来判断 JWT 是否被篡改过。
假如有人篡改了载荷中的信息，再进行编码的话，那么新的头部和载荷的签名跟之前的签名是不一样的，并且如何加密的密钥不一样的话，得出来的签名结果也会不一样。
JWT使用场景
- Authentication（鉴权）
这是使用JWT最常见的情况。 一旦用户登录，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由，服务和资源。 单点登录是当今广泛使用JWT的一项功能，因为它的开销很小，并且能够轻松地跨不同域使用。
- Information Exchange（信息交换）
JSON Web Tokens是在各方之间安全传输信息的好方式。 因为JWT可以签名：例如使用公钥/私钥对，所以可以确定发件人是他们自称的人。 此外，由于使用标头和有效载荷计算签名，因此您还可以验证内容是否未被篡改。
以上就是 JSON Web Token 相关知识，希望这篇文章对您的学习或者工作有所帮助，如果您觉得文章有帮助，欢迎帮忙转发，谢谢。
最后
目前互联网上很多大佬都有 JSON Web Token 相关文章，如有雷同，请多多包涵了。原创不易，码字不易，还希望大家多多支持。若文中有所错误之处，还望提出，谢谢。
欢迎扫码关注微信公众号：「互联网平头哥」，和平头哥一起学习，一起进步。