一分钟简单了解 JSON Web Token

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 相关文章，如有雷同，请多多包涵了。原创不易，码字不易，还希望大家多多支持。若文中有所错误之处，还望提出，谢谢。

欢迎扫码关注微信公众号：「互联网平头哥」，和平头哥一起学习，一起进步。