目录

0.相关文章（实际运用）

1. 头部（Header）

2. 负载（Payload）

3. 签名（Signature）

完整的 JWT 字符串示例

总结与关键点

---

=======================

超级简介

头部.负载.签名

=======================文章开始

0.相关文章（实际运用）

======

使用 javax.net.ssl.HttpsURLConnection 发送 HTTP 请求__以及为了JWT通信选用OSS的Jar的【坑】__以及（WebSphere）【证明书】相关内容说明-CSDN博客

======

1. 头部（Header）

头部通常是一个 JSON 对象，它描述了关于该 JWT 的最基本的信息，例如其类型以及所使用的签名或加密算法。

• 作用： 声明令牌的类型和使用的算法。

• 内容示例：

  json

  {
    "alg": "HS256",
    "typ": "JWT"
  }

  • alg (algorithm)： 表示签名的算法，例如 HS256（HMAC SHA-256）或 RS256（RSA SHA-256）。这是必选字段。

  • typ (type)： 表示令牌的类型，这里当然是 JWT。有时还会有 cty (content type) 等其它字段。

这个 JSON 对象会经过 Base64Url 编码，形成 JWT 的第一部分。

---

2. 负载（Payload）

负载部分包含了所要传递的“声明”（Claims）。声明是关于实体（通常是用户）和附加元数据的语句。声明分为三种类型：

• 作用： 携带需要传递的实际信息。

• 内容类型：

  1. 已注册的声明（Registered Claims）： 预定义的一组标准声明，建议但不强制使用。它们通常有通用的含义：

     • iss (issuer)： 签发者

     • sub (subject)： 主题（用户ID等）

     • aud (audience)： 受众（接收该JWT的一方）

     • exp (expiration time)： 过期时间（Unix时间戳）

     • nbf (not before)： 生效时间（在此之前不可用）

     • iat (issued at)： 签发时间

     • jti (JWT ID)： 令牌的唯一标识，用于防止重放攻击

  2. 公共的声明（Public Claims）： 可以由使用 JWT 的人员随意定义。但为了避免冲突，应在 IANA JSON Web Token Registry 中定义或使用一个包含抗冲突命名空间的名称。

  3. 私有的声明（Private Claims）： 在提供者和消费者之间共同约定的自定义声明，用于共享信息，既不是已注册声明也不是公共声明。

  示例 Payload:

  json

  {
    "sub": "1234567890",
    "name": "John Doe",
    "iat": 1516239022,
    "admin": true
  }

  这个 JSON 对象同样会经过 Base64Url 编码，形成 JWT 的第二部分。

⚠️ 重要提示： 虽然负载可以被解码（Base64Url解码），但它默认是不加密的。任何人拿到令牌后都可以解码看到负载内容。因此，绝对不要在 JWT 的负载或头部中放置敏感信息（如密码）。如果需要保密，应使用加密的 JWT（JWE）。

---

3. 签名（Signature）

签名部分是整个 JWT 最关键的部分，用于验证消息在传递过程中没有被篡改，并且（在使用非对称加密时）可以验证发送方的身份。

• 作用： 验证令牌的完整性和真实性。

• 生成方式： 将编码后的头部、编码后的负载、以及一个密钥（secret） 通过头部指定的算法（如 HS256）进行签名。
  签名 = 算法(encodedHeader + '.' + encodedPayload, secret)

  • 例如，使用 HMAC SHA256 算法的签名是这样产生的：

    java

    HMACSHA256(
      base64UrlEncode(header) + "." + base64UrlEncode(payload),
      secret
    )

签名生成后，也会进行 Base64Url 编码，最终形成 JWT 的第三部分。

---

完整的 JWT 字符串示例

将上述三个部分组合起来，就形成了一个完整的 JWT：

1. 编码后的 Header:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

2. 编码后的 Payload:
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

3. 使用密钥 your-256-bit-secret 生成的 Signature:
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

最终的 JWT:

text

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

你可以将这个令牌粘贴到 jwt.io 的调试器中，直观地看到它的解码结果。

总结与关键点

部分	内容	是否加密	作用
Header	元数据（算法、类型）	否（仅Base64Url编码）	声明如何验证签名
Payload	需要传递的数据（声明）	否（仅Base64Url编码）	携带实际信息
Signature	对前两部分的签名	N/A	验证完整性，防止篡改

• 完整性验证： 接收方收到 JWT 后，会用同样的算法和密钥对前两部分重新计算签名。如果计算结果与第三部分不匹配，说明令牌被篡改或无效，应立即拒绝。

• 安全性： JWT 的安全性完全依赖于签名和密钥的保密性。如果签名密钥泄露，攻击者可以伪造任何令牌。

• 不是加密： 标准的 JWT（JWS）是签名而不是加密。它保证数据不被篡改，但不保证数据不被他人看见。如需保密，请使用 JWE（JSON Web Encryption）。