JWT解码器
粘贴JWT(JSON Web Token)即可立即解码其Header和Payload,并附带过期时间(exp)判断。本工具不进行签名验证,也无需输入密钥。
常见注册声明(Registered Claims)一览
| 声明 | 名称 | 说明 |
|---|---|---|
| iss | Issuer(签发者) | 标识签发该令牌主体的字符串或URL。 |
| sub | Subject(主题) | 令牌所指代的对象(通常为用户ID)。 |
| aud | Audience(受众) | 该令牌预期使用者或API的标识符。 |
| exp | Expiration Time(过期时间) | 此时间(Unix秒)之后不应再接受该令牌。 |
| nbf | Not Before(生效时间) | 此时间(Unix秒)之前不应接受该令牌。 |
| iat | Issued At(签发时间) | 令牌的签发时间(Unix秒)。 |
| jti | JWT ID | 用于唯一标识令牌的ID,常用于防重放攻击的重复检测。 |
使用提示
- 您输入的JWT仅在浏览器内通过JavaScript处理,不会发送到toolbase.cc的服务器,令牌中包含的个人信息或凭证也不会外泄。
- JWT是由Header、Payload、签名三部分以英文句点(.)分隔的Base64URL字符串。Header和Payload是任何人都可以解码的明文(Base64是编码而非加密),因此切勿在Payload中放入密码等敏感信息。
- 如果API请求因令牌过期而返回401错误,先用本工具查看
exp声明的值,可以更快定位问题原因。 - 签名算法可在
alg头部字段中查看。允许alg: none的实现存在绕过签名验证的安全漏洞(即JWT的alg=none攻击),因此服务器端必须显式限制可接受的算法列表。
常见问题
是的。JWT的Header和Payload采用的是Base64URL编码而非加密,因此任何人都可以读取其内容。密码、信用卡号等敏感信息不应放入Payload中。
不能,本工具仅对Header和Payload进行解码显示,不会验证签名。验证签名需要只有令牌签发者才掌握的密钥(或RSA/EC公钥),出于安全考虑,这类密钥本就不应该输入到浏览器工具中。
大多数API和认证服务器会拒绝
exp 声明早于当前时间的JWT,并返回401 Unauthorized等错误。此时需要重新获取令牌,例如通过刷新令牌重新签发。
闲话 ― JWT如何实现「无状态认证」
JWT(JSON Web Token)于2015年由IETF标准化为RFC 7519。传统的基于会话的认证方式需要服务器保存会话ID与用户信息的对应表,而JWT则将用户信息本身嵌入令牌内,并通过签名来检测篡改。这使得服务器无需维护会话存储即可验证认证状态,即所谓的「无状态认证」,因此被广泛应用于跨多台服务器的分布式系统和微服务之间的身份认证。
JWT的结构由「Header.Payload.签名」三部分组成,每部分都经过Base64URL编码后以句点连接。需要特别注意的是,Header和Payload只是编码,并非加密。任何人都可以解码并读取其内容,因此JWT保证的是「内容未被篡改」,而不是「内容被保密」。如果需要保密信息,则需要使用另一项加入了加密功能的规范——JWE(JSON Web Encryption)。
签名方式大致可分为两类:发送方与接收方共享同一密钥的HMAC方式(如HS256),以及用私钥签名、用公钥验证的公钥加密方式(如RS256、ES256)。自JWT被OAuth 2.0和OpenID Connect采用为访问令牌与ID令牌的格式以来,它已成为Web认证体系事实上的标准格式。