首页JWT编码/解码

JWT编码/解码

JSON Web Token (JWT) 调试、编码和解码工具。支持签名验证 (HS256/RS256),全过程浏览器本地处理

解码后的 JWT

头部

载荷

签名

                  

JSON Web Tokens (JWT) 权威指南

什么是 JWT (JSON Web Token)?

JSON Web Token (JWT) 是一个开放标准 (RFC 7519),定义了一种紧凑且自包含的方式,用于作为 JSON 对象在各方之间安全地传输信息。这些信息可以被验证和信任,因为它们经过了数字签名。JWT 可以使用密钥(HMAC 算法)或公钥/私钥对(RSA 或 ECDSA)进行签名。由于采用了 Base64Url 编码,体积小,可以通过 URL、POST 参数或 HTTP 头部发送。

JWT 的结构

一个 JWT 技术上由三部分组成,用点 (.) 分隔,分别是:

xxxxx.yyyyy.zzzzz
  • Header: 头部 (Header):通常由两部分组成:令牌的类型 (即 JWT) 和所使用的签名算法,例如 HMAC SHA256 或 RSA。
  • Payload: 载荷 (Payload):载荷包含声明 (Claims)。声明是关于实体(通常是用户)和其他数据的陈述。声明有三种类型:注册的、公开的和私有的声明。
  • Signature: 签名 (Signature):要创建签名部分,您必须获取编码后的头部、编码后的载荷、一个密钥、头部中指定的算法,并对其进行签名。签名用于验证消息在传输过程中未被更改。

支持的算法

本工具支持解码和验证所有标准算法,以及生成对称加密算法的令牌:

算法类型描述
HS256对称HMAC SHA-256,需要共享密钥,速度快,常用于微服务
HS384对称HMAC SHA-384,使用 384 位哈希,抗碰撞性更高
HS512对称HMAC SHA-512,使用 512 位哈希,对称签名中最安全的
RS256非对称RSA SHA-256,使用私钥签名、公钥验证,非常适合公共 API
RS384/RS512非对称RSA SHA-384/512,更高的安全级别

理解 JWT 声明 (Claims)

声明是关于主体的断言信息。标准的注册声明包括:

  • iss (Issuer): 签发人,标识颁发 JWT 的实体。
  • sub (Subject): 主体,标识 JWT 所面向的用户或实体。
  • aud (Audience): 受众,标识 JWT 预期的接收者。
  • exp (Expiration Time): 过期时间,标识 JWT 不再被接受的时间点。
  • nbf (Not Before): 生效时间,标识在此时间之前 JWT 不可被接受。
  • iat (Issued At): 签发时间,标识 JWT 的签发时间。
  • jti (JWT ID): 提供 JWT 的唯一标识符。

何时使用 JWT?

  • 授权:最常见的场景。用户登录后,每个后续请求都会携带 JWT,从而允许用户访问令牌所允许的路由、服务和资源。
  • 信息交换:JWT 是在各方之间安全传输信息的一种良好方式。由于 JWT 可以签名,接收方可以验证发送方的身份并确保消息未被篡改。
  • 无状态会话:与服务器端会话不同,JWT 包含所有必要的用户数据,减少了对会话状态的数据库查询。
  • 跨域单点登录 (SSO):由于 JWT 是无状态且体积小,很容易在不同域之间传递以实现单点登录。
  • API 安全:在无需维护服务器端会话状态的情况下保护 RESTful API。

安全最佳实践 1)不要在载荷中放置敏感数据(如密码),任何人都可以通过 Base64 解码读取。2)始终验证签名。3)使用 exp 声明限制令牌有效期。4)使用 HTTPS 防止令牌被窃听。5)安全地存储令牌(推荐使用 HttpOnly Cookie 而不是 LocalStorage 以降低 XSS 风险)。

参考资料

  • RFC 7519 - JSON Web Token (JWT) 规范
  • JWT.io - 官方行业资源
  • MDN Web Docs: Crypto API

常见问题 (FAQ)

JWT 是加密还是编码?

标准 JWT 是编码并签名的,而不是加密。载荷使用 Base64Url 编码,这意味着任何人都可以解码并阅读。签名确保数据未被篡改,但不会隐藏数据。如果需要机密性,应使用 JWE(JSON Web Encryption)。

客户端应该把 JWT 存在哪里?

对于 Web 应用,将 JWT 存在 HttpOnly Cookie 中通常被认为比存储在 localStorage 更安全,因为 Cookie 无法被 JavaScript 直接读取,从而降低 XSS 风险。但 Cookie 仍然可能受到 CSRF 攻击,需要额外的防护措施。

如果 JWT 泄漏会发生什么?

如果 JWT 被盗,攻击者可以在令牌过期前冒充该用户。因此必须设置较短的过期时间 (exp),并实现令牌吊销策略(例如黑名单 jti),或使用带轮换的刷新令牌。

此工具会把我的密钥发送到服务器吗?

不会。此工具完全在客户端运行。您的私钥、密钥和令牌数据永远不会离开浏览器。所有加解密操作都在本地通过 JavaScript 库完成。

我可以手动修改载荷吗?

您可以在本地修改载荷,但这会使基于原始密钥的签名失效。除非使用正确的密钥/私钥重新签名,否则服务器会拒绝该令牌。

HS256 和 RS256 有什么区别?

HS256 是对称算法(同一个共享密钥用于签名和验证)。RS256 是非对称算法(私钥用于签名,公钥用于验证)。在需要多个服务验证但不能生成令牌的分布式系统中,RS256 更合适。

JWT 的载荷是什么?

载荷包含声明,即关于实体(通常是用户)和其他数据的陈述。载荷通过 Base64Url 编码,任何人都可以读取,因此不要在其中放置密码等敏感信息。常见声明包括用户 ID (sub)、过期时间 (exp)、签发时间 (iat) 等。

为什么签名验证失败?

签名验证失败可能有多种原因:1)使用了错误的密钥或公钥;2)令牌在传输过程中被修改;3)令牌使用的算法与验证时指定的不一致;4)对于 RSA/ECDSA 算法,公钥格式不正确或与签名时使用的私钥不匹配。请确保使用与生成令牌时相同的密钥和算法。

数据默认在您的本地浏览器上处理,不会上传至服务器。如需上传会明确提示。

© 2026 See-Tool. 保留所有权利。 | 联系站长