【jwt解码】深入剖析JWT解码的方方面面

【jwt解码】深入剖析JWT解码的方方面面

JSON Web Token（JWT）已成为现代Web应用中安全、紧凑且可信的认证信息传输方式。它通常用于在客户端和服务器之间传递用户身份、权限等信息。而“JWT解码”则是我们理解和操作这些令牌的第一步。本文将围绕JWT解码的“是什么”、“为什么”、“哪里发生”、“能得到多少信息”、“如何操作”以及“安全考量”等通用疑问，为您提供一份详尽且具体的指南。

一、JWT解码：它“是什么”？

JWT解码，顾其名，就是将一个经过编码的JWT字符串还原成其原始的、可读的JSON数据结构的过程。一个典型的JWT由三部分组成，这三部分之间用点（`.`）分隔：

1. 头部（Header）：通常包含令牌的类型（typ，一般为“JWT”）和所使用的签名算法（alg，例如HMAC SHA256或RSA）。
   
   编码前示例：

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

2. 载荷（Payload）：包含实体（通常是用户）的声明（claims）。声明是关于实体和其他数据的语句。有三种类型的声明：
   • 注册声明（Registered Claims）：预定义的一些常用声明，例如：
     • iss (issuer)：签发者
     • sub (subject)：主题
     • aud (audience)：接收方
     • exp (expiration time)：过期时间，通常是Unix时间戳
     • nbf (not before)：在此之前不予处理的时间
     • iat (issued at)：签发时间
     • jti (JWT ID)：JWT的唯一标识符
   • 公共声明（Public Claims）：可以随意定义，但为了避免冲突，应该在IANA JSON Web Token Registry中注册，或者作为URI。
   • 私有声明（Private Claims）：自定义的声明，用于在同意使用这些声明的各方之间共享信息，没有注册，可能与其他人冲突。例如，用户角色（roles）、用户ID（userId）等。

   编码前示例：

   
   {
     "sub": "1234567890",
     "name": "John Doe",
     "iat": 1516239022,
     "exp": 1516242622,
     "roles": ["admin", "user"]
   }
           

3. 签名（Signature）：用于验证JWT的发送者，并确保消息在传输过程中没有被篡改。它是通过对编码后的头部、编码后的载荷以及一个密钥（secret）使用头部中指定的算法进行哈希计算得出的。

解码JWT，特别是针对头部和载荷部分，实际上就是对这两部分进行Base64url解码。由于Base64url编码是可逆的，所以任何人都可以对JWT的头部和载荷进行解码，获取其中的内容。

重要区分：解码（Decoding）与验证（Verification）

请务必理解，JWT解码不同于JWT验证。解码仅仅是将Base64url编码的字符串还原为原始JSON，这个过程不需要任何密钥。而验证则是一个安全关键的步骤，它涉及使用预共享的密钥或公钥来重新计算并比对JWT的签名。只有签名验证通过的JWT，其内容才可被信任。简单来说：

• 解码：还原数据，任何人都能做，不保证数据未被篡改。
• 验证：确保数据来源真实且未被篡改，需要密钥，是安全性的基石。

忽视这一区别可能导致严重的安全漏洞。

二、我们“为什么”需要解码JWT？

尽管解码本身不提供安全性保证，但在许多场景下，JWT解码是必需且非常有用的：

1. 审查和调试：

   在开发、测试或故障排除过程中，我们经常需要查看JWT中到底包含了哪些信息（如用户ID、角色、权限、过期时间等）。通过解码，可以快速了解令牌的内容是否符合预期，或者是否存在错误配置。例如，检查exp（过期时间）声明是否正确设置，以诊断令牌过期问题。

2. 客户端展示信息：

   在一些单页应用（SPA）或移动应用中，可能需要在用户界面上展示一些从JWT中提取出来的非敏感信息，比如用户的昵称、头像URL（如果这些信息被包含在载荷中）。这种情况下，客户端JS库可以直接解码JWT（无需密钥），然后渲染这些信息。但请注意，这些展示的信息绝不能作为后端业务逻辑的依据，后端必须重新验证和解析令牌。

3. 头部信息提取（用于验证目的）：

   在某些复杂的安全架构中，特别是使用非对称加密（如RS256）时，JWT的头部可能包含一个kid（Key ID）声明。这个kid指示了服务器应该使用哪个公钥来验证JWT的签名。在这种情况下，服务器端需要先解码JWT的头部来获取kid，然后根据kid查找对应的公钥，最后再进行完整的签名验证。

4. 提前进行非安全相关的业务判断：

   在极少数情况下，服务器端为了优化性能，可能会在进行完整签名验证之前，先解码JWT的载荷来检查一些非敏感且非关键的信息。例如，检查exp声明是否已经过期。如果已经过期，则可以直接拒绝，而无需进行耗时的签名验证。但这种优化必须谨慎，并确保后续仍然会进行完整的签名验证。

三、JWT解码“哪里”发生？“如何”操作？

JWT解码可以在不同的环境中进行，且操作方式多样。

3.1 解码发生的位置：

• 客户端（浏览器/移动应用）：

  JavaScript（在浏览器中）、Swift/Kotlin（在移动应用中）等语言可以轻松地进行JWT解码。这主要用于获取非敏感信息，如用户名称显示在UI上，或进行本地调试。

• 服务器端（后端服务）：

  任何后端语言（如Node.js, Python, Java, Go, C#等）都支持JWT解码和验证。这是处理JWT最常见且安全的位置。服务器端会利用专门的库来完成解码及后续的签名验证。

• 在线工具：

  许多网站提供在线JWT解码服务（例如jwt.io）。这些工具非常方便，只需粘贴JWT字符串即可立即看到解码后的头部和载荷。它们是快速检查令牌内容的利器，但在处理包含敏感信息的生产JWT时应谨慎使用。

3.2 手动解码“如何”操作？

要理解JWT解码的原理，我们可以尝试手动解码它的头部和载荷：

1. 获取JWT字符串：例如 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
2. 按点（`.`）分隔：将其分成三部分：
   • 第一部分：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 (Header)
   • 第二部分：eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9 (Payload)
   • 第三部分：SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c (Signature)
3. 对前两部分进行Base64url解码：

   JWT使用的是Base64url编码，与标准的Base64编码略有不同。Base64url将URL不友好的字符（+, /, =）替换为URL友好的字符（-, _），并且通常省略填充字符（=）。

   • 将第一部分 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 解码为：

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

   • 将第二部分 eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9 解码为：

     
     {"sub":"1234567890","name":"John Doe","iat":1516239022,"exp":1516242622}
                     

   这样，你就成功手动解码了JWT的头部和载荷。签名部分不能被“解码”成有意义的JSON或文本，它是一个二进制哈希值。

3.3 程序化解码“如何”操作？

在实际开发中，我们通常使用成熟的JWT库来进行解码和验证，这些库处理了Base64url编码/解码的细节，并且提供了更高级的API。

3.3.1 JavaScript (Node.js/Browser) 示例：

使用jsonwebtoken库（Node.js）或jwt-decode库（浏览器端，仅解码）。

// Node.js 环境下使用 jsonwebtoken 进行解码 (通常与验证结合)
// npm install jsonwebtoken
const jwt = require('jsonwebtoken');

const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

try {
    // 仅解码，不验证签名。返回的是Payload对象
    const decodedPayload = jwt.decode(token);
    console.log('解码后的载荷 (Payload):', decodedPayload);

    // 如果想获取头部信息，可以手动解析
    const parts = token.split('.');
    if (parts.length === 3) {
        const decodedHeader = JSON.parse(Buffer.from(parts[0], 'base64url').toString('utf8'));
        console.log('解码后的头部 (Header):', decodedHeader);
    }

    // 推荐做法：在服务器端进行验证，验证成功后会返回Payload
    // const secret = 'your_secret_key'; // 你的密钥
    // const verifiedPayload = jwt.verify(token, secret);
    // console.log('验证后的载荷:', verifiedPayload);

} catch (error) {
    console.error('JWT解码或验证失败:', error.message);
}

// 浏览器端使用 jwt-decode 进行解码 (仅解码，不验证)
// npm install jwt-decode (或者通过CDN引入)
// import jwt_decode from 'jwt-decode'; // ES Module
// const jwt_decode = require('jwt-decode'); // CommonJS

// const tokenBrowser = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';
// const decodedBrowser = jwt_decode(tokenBrowser);
// console.log('浏览器端解码:', decodedBrowser);
// console.log('头部:', jwt_decode(tokenBrowser, { header: true })); // 获取头部

3.3.2 Python 示例：

使用PyJWT库。

# Python 环境下使用 PyJWT 进行解码
# pip install PyJWT
import jwt
import json # 用于打印美化

token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
secret = 'your_secret_key' # 用于签名的密钥，解码本身不需要，但验证需要

try:
    # 仅解码头部（options={"verify_signature": False} 或 get_unverified_header）
    # PyJWT的decode方法默认会尝试验证签名，所以我们需要明确告诉它只解码不验证
    header = jwt.get_unverified_header(token)
    print("解码后的头部 (Header):")
    print(json.dumps(header, indent=2, ensure_ascii=False))

    # 仅解码载荷（不验证签名）
    # 注意：这里的算法指定是为了满足decode方法的签名检查要求，但我们通过verify_signature=False跳过实际验证
    # 更安全的方法是使用get_unverified_claims，或者在verify_signature=False时提供一个虚拟算法
    payload = jwt.decode(token, options={"verify_signature": False})
    print("\n解码后的载荷 (Payload):")
    print(json.dumps(payload, indent=2, ensure_ascii=False))

    # 推荐做法：在服务器端进行验证，验证成功后会返回Payload
    # 如果签名算法是HS256，则需要提供secret
    # 如果是RS256等非对称算法，需要提供公钥
    # verified_payload = jwt.decode(token, secret, algorithms=["HS256"])
    # print("\n验证后的载荷:")
    # print(json.dumps(verified_payload, indent=2, ensure_ascii=False))

except jwt.ExpiredSignatureError:
    print("JWT已过期")
except jwt.InvalidTokenError as e:
    print(f"无效的JWT: {e}")
except Exception as e:
    print(f"发生错误: {e}")

上述代码示例展示了如何使用流行的库进行JWT的解码操作。请注意，当在服务器端处理JWT时，始终优先使用带有签名验证功能的API，而不是仅仅解码。

四、解码后“能得到多少”信息？

成功解码JWT的头部和载荷后，你将获得两个JSON对象，它们包含了编码前置入的所有数据：

• 头部信息：
  • typ (Type)：通常是”JWT”。
  • alg (Algorithm)：用于签名的算法，例如”HS256″、”RS256″、”ES256″等。
  • 其他可能的字段，如kid (Key ID)，在公钥场景下用于指定验证令牌的公钥。
• 载荷信息（声明）：

  这部分是信息的宝库，它包含了一系列键值对，即“声明”。你可以获取到：

  • 注册声明的值：
    • iss：令牌的签发者（例如，“your-auth-service.com”）。
    • sub：令牌的主题，通常是用户ID或用户名（例如，“user123”）。
    • aud：令牌的受众，指定令牌预期接收者（例如，“your-api-gateway”）。
    • exp：过期时间（Unix时间戳）。这是一个非常重要的声明，尽管在解码时你能看到它，但实际应用中必须在验证阶段检查它。
    • iat：签发时间（Unix时间戳）。
    • nbf：在此时间之前，令牌不可用（Unix时间戳）。
    • jti：JWT的唯一标识符，可用于防止重放攻击。
  • 公共声明的值：如果定义了，例如URI指向的特定声明。
  • 私有声明的值：这是最灵活的部分，可以包含任何与业务逻辑相关的非敏感数据，例如：
    • userId：用户数据库中的ID。
    • roles：用户的角色列表（例如，`[“admin”, “viewer”]`）。
    • permissions：用户拥有的具体权限列表。
    • email：用户的电子邮件地址。
    • name：用户的显示名称。
    • 任何其他您认为适合在令牌中传输的非敏感、非关键数据。
• 签名部分本身：

  虽然签名本身不能被“解码”成有意义的结构，但它的存在是验证JWT完整性的关键。解码过程会告诉你它存在，但不会解析其内容，因为它是哈希值，需要与密钥进行验证。

总结来说，解码JWT能让你获取到令牌中存储的所有可读信息，但获取这些信息并不意味着它们是可信的或未被篡改的。

五、JWT解码的【安全考量】与【注意事项】？

理解JWT解码的局限性和安全隐患至关重要：

1. 解码不等于安全：绝不信任未验证的JWT内容！

   这是最重要的原则。由于JWT的头部和载荷仅是Base64url编码，任何人都可以轻易解码它们。这意味着一个恶意用户可以篡改编码后的头部或载荷，然后重新Base64url编码，生成一个新的“假”JWT。如果没有签名验证，你的应用程序就会接受这个被篡改的令牌，并可能基于其中的虚假信息执行操作，导致严重的安全漏洞（如权限绕过、身份冒用等）。
   
   任何服务器端接收到的JWT，在将其内容用于任何业务逻辑判断之前，都必须进行严格的签名验证。

2. 敏感信息不应置于载荷中：

   即使有签名保护，JWT也只是编码而不是加密。这意味着令牌中的所有信息都是公开可见的（通过解码）。因此，绝不能将真正敏感的信息（如用户密码、信用卡号、私有API密钥等）直接放入JWT的载荷中。载荷应只包含用于身份验证和授权的非敏感信息，或者指向这些敏感信息存储位置的引用。

3. 客户端解码的用途受限：

   在浏览器或移动应用中解码JWT仅限于获取用于UI展示的非敏感信息（例如，显示用户名或头像）。这些信息必须是“仅供显示”的，且客户端绝不能基于这些解码出来的信息进行任何安全敏感的决策（如判断用户是否为管理员）。所有安全决策都必须在服务器端，在令牌经过严格验证后进行。

4. 处理exp（过期时间）声明：

   尽管exp声明在解码后是可见的，但为了确保JWT的有效性，其过期检查必须作为签名验证的一部分来执行，而不是简单地在解码后检查时间戳。大多数JWT库的验证方法会自动处理exp、nbf等时间相关声明的校验。

5. 防止信息泄露：

   如果你的JWT在客户端（如通过URL参数或非HTTP Only Cookie）暴露，且其中包含了一些不应被公众看到的信息，即使它们不是极度敏感的，也可能导致信息泄露。设计JWT时，只包含必要且公开的信息。

通过深入理解JWT解码的“是什么”、“为什么”、“哪里”、“多少”、“如何”以及“安全考量”，我们可以更安全、更高效地在应用中利用这一强大的认证机制。记住，解码是第一步，验证才是安全的关键。