开发者工具·JWT解码器
JWT 剖析：点分割和 Base64url 解码
· 工作原理
杰威特 编码 安全
JWT 是由点分隔的三个 base64url 段。这篇文章手动解码每个部分，解释为什么签名段不是文本，并显示解码器可以和不能告诉您什么。
授权标头中的长字符串 - 您正在查看的内容以及为什么它恰好有两个点
持有者令牌通常以紧凑的点分隔字符串形式到达授权标头。紧凑 JWS 形式的典型签名 JWT 具有三个段，因此有两个分隔点。活动令牌是一种凭证：请勿将生产令牌粘贴到演示中。
紧凑序列化 — 标头、有效负载和签名作为三个 base64url 段
在紧凑型 JWS 序列化中，第一段是受保护的标头，第二段是有效负载，第三段是签名或 MAC。签名覆盖编码的前两个片段，通过点连接。分割字符串定位段；它无法建立信任。
不带填充的 Base64url — JWS 使用的字母表以及为什么这些段没有尾随等号
Base64url 使用 - 和 _ 代替普通 Base64 中的 + 和 /。紧凑型 JWS 省略尾随 = 填充；解码器可以在解码之前恢复填充。解码产生字节。对于 JSON 标头和声明，在解析文本之前将字节解码为 UTF-8 。
标头 — 一个小的 JSON 对象，命名算法，并且通常是密钥
标头通常是 JSON ，包含 alg，有时还包含密钥标识符kid。这些是令牌本身做出的断言。验证者必须执行自己的允许算法策略并安全地获取适当的密钥；单独读取 alg 并不是授权。
有效负载——声明的 JSON 对象，任何持有令牌的人都可以读取
有效负载包含 sub、exp 和 aud 等声明。任何持有该令牌的人都可以读取它们；编码不是加密。 exp NumericDate 计算自 Unix 纪元以来的秒数，但未经验证的声明没有权威。不要将机密存储在可读的有效负载中。
签名——前两段的原始字节，作为文本毫无意义，没有密钥就毫无用处
最后一段是以 base64url 编码的签名字节，而不是第三个 JSON 对象。验证它需要加密算法、密钥和应用程序策略。 ToolAcre 故意不执行验证：它报告签名存在并始终将签名验证标记为 false。
工作示例 - 逐段解码示例令牌，包括出现的 JSON
采用非敏感演示标头 {"alg":"HS256","typ":"JWT"} 和负载 {"sub":"demo"}。它们的base64url编码是eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9和eyJzdWIiOiJkZW1vIn0。解码恢复 JSON。附加任意第三段并不会使令牌变得真实。
要点：解码是读取，而不是信任 - ToolAcre JWT 解码器显示标头和有效负载，但从不验证签名，因此它显示的任何内容都不能证明令牌是真实的
解码是阅读，而不是信任。使用 ToolAcre JWT 解码器来获取一次性令牌的标头、声明和警告；使用应用程序的可信验证程序来确定签名令牌是否有效。仅显示的声明绝不能授予访问权限。