JWT介绍及常见问题

最新推荐文章于 2025-04-18 15:08:50 发布

GeekingWay

最新推荐文章于 2025-04-18 15:08:50 发布

阅读量878

点赞数 13

文章标签：前端网络 javascript

本文链接：https://blog.csdn.net/2301_81071716/article/details/143670018

版权

1

q1:payload中的字串是什么意思

a1:

在JWT（JSON Web Token）中，payload是用于存储声明（claims）的部分，这些声明是关于实体（通常是用户）和其他数据的。在你的图片中，payload部分包含了以下信息：

- `sub`（Subject）: 表示主题，通常是用户的唯一标识符，比如用户ID。
- `name`: 用户的名称。
- `iat`（Issued At）: 表示令牌的签发时间，是一个时间戳。
- `exp`（Expiration Time）: 表示令牌的过期时间，是一个时间戳。

这些声明可以被用来验证用户的身份，以及获取关于用户的其他信息。例如，`sub`可以用于确认令牌是否属于特定的用户，`iat`和`exp`可以用于检查令牌是否在有效期内。

在安全通信中，payload是被加密或签名的，以确保数据的完整性和真实性。在图片中，payload被编码为base64Url格式，这是JWT标准中用于编码payload的格式。解码后，我们可以看到这些声明的原始JSON格式。

2

q2:说清楚jwt的工作原理和客户端与服务端交互时具体的流程

a2:

JWT（JSON Web Token）是一种用于在网络应用环境间传递声明的紧凑的、URL安全的令牌标准。它由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。

1. **头部（Header）**：通常包含令牌的类型（如JWT）和所使用的签名算法（如HMAC SHA256或RSA）。

2. **载荷（Payload）**：包含声明，这些声明是关于实体（通常是用户）和其他数据的。声明可以是注册的（如iss、exp、sub等），公共的（如name、admin等），或者私有的（自定义声明）。

3. **签名（Signature）**：使用头部中指定的算法和密钥生成，确保令牌在传输过程中未被篡改。

JWT的工作原理涉及以下几个步骤：

1. **客户端登录**：用户通过提供凭据（如用户名和密码）登录。

2. **服务端验证**：服务端验证凭据，如果验证成功，生成一个JWT。

3. **生成JWT**：JWT包括头部、载荷和签名。头部和载荷被编码为Base64Url格式，然后使用密钥进行签名。

4. **发送JWT**：服务端将生成的JWT发送给客户端。

5. **客户端存储JWT**：客户端收到JWT后，通常将其存储在本地存储（如Cookie或LocalStorage）中。

6. **客户端请求服务端**：客户端在后续的请求中将JWT作为Authorization头的一部分发送给服务端。

7. **服务端验证JWT**：服务端接收到请求后，提取JWT并验证其签名和有效性。如果验证通过，服务端处理请求并返回响应。

8. **使用JWT**：服务端可以使用JWT中的信息（如用户角色、权限等）来授权用户访问特定的资源或执行特定的操作。

JWT的优势在于它是自包含的，不需要服务端存储会话信息，这使得它非常适合分布式系统和微服务架构。此外，JWT可以跨域使用，支持跨域认证，并且由于其无状态性，可以轻松扩展。

在客户端与服务端的交互中，JWT通常通过HTTP请求的Authorization头发送，格式为`Authorization: Bearer <token>`。服务端在接收到请求后，会解析Authorization头中的JWT，并进行验证。如果JWT有效，服务端会根据JWT中的信息来处理请求；如果无效，服务端会返回错误响应。

JWT的安全性依赖于密钥的保密性，因此密钥不应泄露给客户端或其他不可信的实体。此外，JWT一旦签发，就无法被服务端撤销，除非等到其过期。因此，JWT的有效期应根据实际需求合理设置。

3

q3:详细说明一下jwt的加密和解密过程

a3:

JWT（JSON Web Token）的加密和解密过程实际上是一个签名和验证签名的过程。JWT本身并不加密，但它可以通过签名来确保数据的完整性和验证发送者的身份。以下是JWT的加密和解密（签名和验证签名）过程的详细说明：

1. **头部（Header）**：首先，JWT的头部通常包含令牌的类型（即JWT）和所使用的签名算法（如HMAC SHA256或RSA）。这个头部信息被编码为Base64Url格式。

2. **载荷（Payload）**：接着，载荷部分包含声明，这些声明是关于实体（通常是用户）和其他数据的。载荷同样被编码为Base64Url格式。

3. **签名（Signature）**：为了生成签名，首先将头部和载荷的Base64Url编码后的字符串用点（.）连接起来。然后，使用头部中指定的签名算法和密钥对这个连接后的字符串进行签名。签名的目的是确保令牌在传输过程中未被篡改。

4. **合并**：最后，将编码后的头部、载荷和签名用点号连接起来形成完整的JWT。

在客户端与服务端的交互中，当用户成功登录后，服务端会生成一个JWT并发送给客户端。客户端在后续的请求中将JWT作为Authorization头的一部分发送给服务端。服务端接收到请求后，会提取JWT并验证其签名。如果签名验证通过，服务端会认为JWT是有效的，并从中提取信息（如用户身份）来处理请求。

需要注意的是，JWT的签名过程使用的是私钥，而验证签名的过程使用的是公钥或者相同的密钥（取决于使用的是对称加密还是非对称加密）。由于签名过程不涉及加密，JWT的载荷部分实际上是可以被解码和读取的，因此不应该在JWT中包含敏感信息。

JWT的工作流程包括令牌的生成、传输和验证。生成令牌时，将头部和载荷进行编码，并使用指定的算法创建签名。发送令牌时，将创建的JWT发送给需要访问信息的一方，通常通过HTTP标头进行传输。验证令牌时，接收方使用相同的密钥和算法解码头部和负载，并验证签名的完整性。

在实际使用中，JWT广泛应用于身份验证和信息传递，但需要谨慎处理以确保安全性。例如，可以在负载中设置过期时间（exp字段），以确保令牌在一定时间后失效。此外，选择适当的签名算法也是确保系统安全的重要措施。

4

q4:详细说明一下"使用头部中指定的签名算法和密钥对这个连接后的字符串进行签名"这个过程

a4:

在JWT中，签名过程是确保令牌的完整性和验证发行者的关键步骤。这个过程涉及到以下几个关键点：

1. **头部（Header）**：头部通常包含令牌的类型（即JWT）和所使用的签名算法（如HMAC SHA256或RSA）。例如，头部可能看起来像这样：
```json
{
"alg": "HS256",
"typ": "JWT"
}
```
这个头部会被编码为Base64Url格式。

2. **载荷（Payload）**：载荷包含声明，这些声明是关于实体（通常是用户）和其他数据的。例如，载荷可能包含用户ID、用户名、角色等信息。载荷同样被编码为Base64Url格式。

3. **签名（Signature）**：签名是使用头部中指定的算法和密钥生成的。这个过程确保了令牌在传输过程中未被篡改，并且可以验证令牌的发行者。

签名的生成过程如下：

- **编码头部和载荷**：首先，将头部和载荷的JSON对象转换为字符串，然后进行Base64Url编码。这两个编码后的字符串用点（`.`）连接起来，形成待签名的字符串。

- **选择签名算法**：根据头部中指定的算法（如HS256或RS256），选择相应的加密算法。

- **使用密钥签名**：
- **对称加密（如HMAC）**：使用相同的密钥进行签名和验证。签名过程通常涉及将待签名的字符串和密钥一起输入到选定的哈希算法中，生成一个固定长度的哈希值。
- **非对称加密（如RSA）**：使用私钥进行签名，公钥用于验证。签名过程涉及将待签名的字符串和私钥一起输入到相应的加密算法中，生成一个签名。

- **生成签名**：将待签名的字符串和密钥输入到选定的算法中，生成签名。这个签名也是Base64Url编码的。

- **连接签名**：最后，将编码后的头部、载荷和签名用点（`.`）连接起来，形成完整的JWT。

例如，如果使用HMAC SHA-256算法，签名的生成过程可能如下：

1. 头部和载荷被编码为Base64Url格式，如：
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
```
2. 使用HMAC SHA-256算法和密钥对这个字符串进行签名，生成签名字符串。
3. 将头部、载荷和签名连接起来，形成完整的JWT。

这个过程确保了JWT的安全性和完整性，因为任何对头部或载荷的篡改都会导致签名验证失败。

5

a5:如果jwt进入了服务器端,这个服务器端怎么去验证这个jwt是否合法

q5:

当JWT进入服务器端后，服务器会进行以下步骤来验证其合法性：

1. **解码JWT**：首先，服务器会解码JWT的头部和载荷部分。由于JWT的头部和载荷部分是Base64Url编码的，服务器需要对这两个部分进行解码以获取原始的JSON格式数据。

2. **提取签名算法**：从解码后的头部中提取签名算法（如HS256或RS256），这是用于验证JWT签名的算法。

3. **验证签名**：服务器使用提取的签名算法和预期的密钥（对于对称加密算法，如HMAC，使用相同的密钥；对于非对称加密算法，如RSA，使用公钥）来验证JWT的签名。服务器会重新计算头部和载荷的签名，并与JWT中的签名部分进行比较。如果两者匹配，则签名验证通过。

4. **验证载荷中的声明**：服务器会检查载荷中的声明，包括：
- `exp`（Expiration time）：检查令牌是否已过期。
- `nbf`（Not Before）：检查令牌是否在生效时间之前。
- `iat`（Issued At）：检查令牌的签发时间是否在可接受的时间范围内。
- `iss`（Issuer）：检查签发者是否是预期的实体。
- `sub`（Subject）：检查主题是否是预期的用户或实体。
- `aud`（Audience）：检查受众是否是预期的接收者。
- `jti`（JWT ID）：检查令牌的唯一标识符。

5. **检查其他安全措施**：如果JWT中包含其他安全措施，如`alg`（Algorithm）字段指定的加密算法，服务器也会进行相应的检查。

如果上述任何一步验证失败，服务器将认为JWT无效或非法。例如，如果签名不匹配，或者JWT中的声明与预期不符，或者使用了错误的算法或密钥，都会被认为是验证失败。

在实际应用中，服务器可能会使用专门的库来处理JWT的验证过程，这些库通常会处理上述所有步骤，并提供简单的API来验证JWT。如果验证失败，服务器可能会返回一个错误响应，如401 Unauthorized状态码，并要求用户重新进行身份验证。

6

q6:这个公钥和私钥都是服务器端的吗

a6:

在使用JWT时，公钥和私钥的使用取决于签名和验证的加密算法类型：

1. **对称加密算法（如HMAC）**：
- 在这种情况下，使用相同的密钥进行签名和验证。这意味着服务器端在生成JWT时使用私钥进行签名，而在验证JWT时也使用相同的私钥进行验证。
- 私钥必须保密，不能泄露给客户端或其他不可信的实体。

2. **非对称加密算法（如RSA）**：
- 在这种情况下，使用一对密钥：私钥和公钥。
- **私钥**：用于签名JWT。私钥必须保密，只有服务器端知道。
- **公钥**：用于验证JWT。公钥可以公开，客户端和服务端都可以使用它来验证签名。
- 服务器端在生成JWT时使用私钥进行签名，而在验证JWT时，客户端或服务器端使用公钥进行验证。

在非对称加密中，公钥和私钥是成对生成的，它们在数学上是相关的，但公钥不能用来推导出私钥。这种特性使得非对称加密非常适合用于安全通信，其中私钥用于签名（确保信息的来源和完整性），而公钥用于验证签名。

在实际应用中，服务器端通常会生成一对密钥，并将公钥提供给需要验证JWT的客户端或其他服务。这样，即使公钥被公开，也不会影响系统的安全性，因为只有私钥能够生成有效的签名。

7

q7:你说在非对称加密算法中,公钥可以公开，客户端和服务端都可以使用它来验证签名,为什么客户端可以验证签名,验证签名的不都是服务器端吗?

a7:

在非对称加密中，公钥确实可以公开，并且不仅服务器端，客户端也可以使用公钥来验证JWT的签名。这种机制是公钥基础设施（PKI）的核心原理，它允许任何持有公钥的实体来验证使用相应私钥签名的数据的完整性和来源。

以下是为什么客户端也可以验证签名的原因：

1. **信任链**：客户端需要信任服务器端的公钥。这通常通过一个信任链来建立，例如，客户端可能从权威的证书颁发机构（CA）获取服务器的公钥，或者在应用安装时嵌入公钥。

2. **验证签名**：客户端使用服务器的公钥来验证JWT的签名。如果签名验证成功，客户端可以确信JWT是由持有相应私钥的服务器端签发的，因为只有私钥能够生成有效的签名。

3. **安全性**：即使客户端可以验证签名，它们也无法伪造签名，因为它们没有私钥。这确保了数据的完整性和来源的验证。

4. **分布式系统**：在分布式系统中，不同的服务或组件可能需要验证JWT。允许客户端验证签名可以减少对中心化服务的依赖，提高系统的灵活性和可扩展性。

5. **客户端逻辑**：在某些应用场景中，客户端可能需要在本地执行一些基于JWT信息的逻辑，例如显示用户的角色或权限。在这种情况下，客户端验证JWT的签名可以确保它正在处理的是有效且未被篡改的数据。

总之，客户端验证JWT签名是一种常见的做法，它有助于确保数据的安全性和完整性，同时也支持分布式系统中的灵活认证和授权。服务器端通常也执行签名验证，以确保处理的JWT是有效的，但客户端的验证是额外的安全层，可以防止在客户端和服务端之间的通信过程中JWT被篡改。
即类似于之前中科大计算机网络的那个Bob,Alice模型(中间有个坏人)