UltKit

JWT解码器

粘贴一个JSON Web Token,即可以格式化的JSON查看其头部和载荷,过期时间和签发时间显示为日期,并提示该Token当前是否有效。解码完全在浏览器中进行,当Token是正在使用的凭证时,这一点尤为重要。

0 个字符 · 0 个词 · 0 行

0 个字符 · 0 个词 · 0 行

完全在当前浏览器标签页中运行,您的文本不会被上传或保存。

注册声明

RFC 7519 §4.1 中定义的七个声明名称,均为可选;时间为自 1970-01-01 UTC 起的秒数。

声明含义
iss签发者:创建并签署令牌的一方
sub主题:令牌所指向的用户或实体
aud受众:令牌的预期接收方
exp过期时间:此时刻之后应拒绝令牌
nbf生效时间:此时刻之前应拒绝令牌
iat签发时间:令牌的创建时间
jtiJWT ID:唯一标识符,用于防止重放

常见 alg 值

alg 值含义
HS256使用 SHA-256 的 HMAC;同一个共享密钥用于签名和验证
RS256使用 SHA-256 的 RSA PKCS#1 v1.5 签名;私钥签名,公钥验证
PS256使用 SHA-256 的 RSA-PSS
ES256P-256 曲线上使用 SHA-256 的 ECDSA;签名较短
EdDSAEd25519 或 Ed448 签名
none未签名的令牌;服务器应拒绝

JSON Web Token的结构

JWT 定义于 RFC 7519(2015 年 5 月),该规范建议读作英文单词 "jot"。常见的签名形式由三段 Base64url 字符串以点号连接:header.payload.signature。header(头部)在 alg 中标明签名算法,如 HS256 或 RS256,通常还会在 kid 中给出密钥 ID。payload(载荷)包含声明(claims),即 JSON 字段,如 sub(用户)、iss(签发方)、aud(目标受众),以及 exp、nbf 和 iat,它们都是自 1970 年 1 月 1 日 UTC 起算的秒数时间。解码器会把这三项转换为你的本地时间和 ISO 8601 格式,并告诉你令牌是已过期、尚未生效,还是处于有效期内。

Base64url 只是一种编码,不是加密,因此任何拿到令牌的人都能像本页一样读取其载荷。切勿把密码、银行卡号或其他机密信息放进声明里。由五段点号分隔的部分组成的令牌是 JWE,即加密令牌;没有密钥就无法读取其内容,解码器也会给出提示。从 Authorization 请求头复制来的开头 "Bearer " 会被自动去掉。

为什么这里不验证签名

签名用于证明头部和载荷由持有密钥的一方生成,且之后未被修改。验证签名需要对应的密钥:HS256 等 HMAC 算法使用共享密钥,RS256、ES256 或 EdDSA 则使用签发方的公钥。把生产环境的签名密钥粘贴到任何网页中都不是好主意,而没有密钥却假装为令牌担保的解码器只会带来虚假的安心,因此本工具只显示签名,不做验证。你看到的内容只是令牌自身的声明,不应当作事实。

验证应在你的服务器上进行,使用维护良好的库,并固定预期的算法。历史上有两个典型错误:一是接受 alg 为 "none" 的令牌,导致任何人都能伪造未签名的令牌;二是算法混淆,即预期 RS256 的服务器被诱导用公钥作为 HMAC 密钥去校验 HS256 签名。解码器适合用于调试:查看服务提供方签发了哪些声明、发现 audience 不对,或者弄清会话失败是因为 exp 刚在一分钟前过期。若要查看原始的 Base64url 片段,请使用 Base64 解码。

常见问题

把真实的访问令牌粘贴到JWT解码器里安全吗?
在本页面中,令牌不会离开你的浏览器。不过有效令牌在过期前等同于密码,因此建议优先使用已过期或测试用的令牌,并避免让正在使用的令牌出现在截图和聊天记录中。
Token刚签发,为什么显示已过期?
先检查设备时钟。有些签发方给访问令牌的有效期只有几分钟,从日志里复制的令牌也可能比看起来更早。若 exp 误用毫秒而不是秒,情况则相反,时间会落在几千年之后。
别人能修改我的JWT载荷吗?
他们可以修改并重新编码,但签名将不再匹配。使用正确密钥和算法校验签名的服务器会拒绝被篡改的令牌。
JWS和JWE有什么区别?
JWS(RFC 7515)是已签名的,由三段组成,任何人都能读取。JWE(RFC 7516)是加密的,由五段组成,只有持有密钥的人才能读取载荷。
退出登录会让JWT失效吗?
仅凭令牌本身做不到。已签名的 JWT 在 exp 之前一直有效,除非服务器维护了黑名单或检查会话记录,这也是访问令牌通常只设置较短有效期的原因。