开发者工具 · JWT 解码器

如何使用 base64 和 jq 手动解码 JWT 有效负载

2026年9月9日 · 工作原理

jwt 命令行开发人员工作流程

在无头盒子上，您仍然可以使用 cut、tr、base64 和 jq 读取令牌。这篇文章提供了命令，解释了每个命令执行的 base64url 转换，并列出了陷阱。

通过 SSH 读取令牌 — 当浏览器不可行时

无头服务器可能会给您留下令牌形状的字符串，并且没有浏览器 UI。所需的检查工作仍然很小：隔离一个段、翻译 base64url 拼写、恢复填充、解码字节并解析 JSON。危险是操作性的而不是计算性的，因为 shell 历史记录可以保存实时凭证。

尽可能使用过期或合成令牌。如果事件响应需要检查真实值，请遵循组织的凭证处理控制措施，防止其进入共享历史记录或日志，并在暴露后轮换它。命令行解码仅保留检查；它不提供验证密钥或信任策略。

紧凑的 JWS 形状 JWT 具有三个点分隔的字段。有效负载是第二个。 shell 可以使用分隔符感知工具将其拆分，但会引用变量，以便 shell 不会扩展字符或拆分空格。在选择字段之前删除前导 `Bearer ` 标签，因为该前缀属于 HTTP 语法。

计算字段数，而不是盲目地取字段二。 ToolAcre 拒绝除三部分以外的任何内容，并单独识别五部分加密输入。外壳管道应采取同样的结构谨慎措施；从格式错误的输入接收片段可以产生合理的 JSON，同时隐藏原始标记被截断。

标准命令行 Base64 实现通常需要加号和斜杠，其中 JWT 段可能包含连字符和下划线。将 `-` 转换为 `+` 并将 `_` 转换为 `/` 将 URL 安全符号映射回其标准位置，而不更改表示的六位值。

使用其选项解析不能将前导连字符误认为标志的翻译命令，并将数据保留在带引号的变量或标准输入中。字母转换是可逆的编码工作。它不会解密声明，并且成功并不能确定令牌来自指定的发行者。

转换后，计算长度模四。余数零不需要等号，余数二需要两个，余数三需要一。余数 1 表示截断，应停止管道。附加任意填充直到公用事业停止抱怨可能会隐藏损坏而不是诊断它。

ToolAcre 在 `base64ToBytes` 中完全使用此长度规则，并拒绝不可能的余数。 Shell 实用程序在是否接受省略的填充方面有所不同，因此首先规范化输入使管道在概念上变得明确和可移植，尽管命令标志在操作系统之间仍然可能有所不同。

将填充值通过管道传输到平台的 Base64 解码器，然后传输到 `jq`。第一个命令恢复字节；第二个需要这些字节形成 JSON。成功的 Base64 命令后跟 jq 解析错误意味着编码在结构上是可解码的，但其内容不是 JSON 有效负载。

这种区别反映了 ToolAcre 的错误路径。它首先报告无效的base64url或UTF-8，然后单独报告无效的JSON，然后拒绝null、数组和基元，因为JWT标头或有效负载必须是该工具的对象。将阶段分开可以使失败变得可行。

作为一个综合示例，有效负载段 `eyJzdWIiOiJkZW1vIiwicm9sZSI6InJlYWRlciJ9` 不需要字母转换或填充。解码产生 `{"sub":"demo","role":"reader"}` 和跨行对象的 jq 格式。可见角色只是令牌提供的字符串。

现在更改 JSON，再次对其进行编码并附加任何第三段。管道仍然打印更改的对象。这证明了为什么解码命令不能用作有效性检查：合法和捏造的声明都会遍历相同的公共转换，除非单独的验证者检查签名。

常见失败包括保留 HTTP 前缀、选择错误的点分隔字段、复制过程中丢失尾随字符以及使用需要填充的 Base64 实现。另一个陷阱是将整个令牌直接放在命令行上，进程列表或历史记录可能会保留它。

更喜欢在适当控制下的标准输入和临时变量，并且切勿为了方便而将生产令牌粘贴到聊天、票证或共享终端中。另请记住，第三段是二进制签名材料，而不是 JSON，因此通过 jq 发送它应该会失败，并且不会告诉您任何有关签名有效性的信息。

shell 管道和 ToolAcre 在不同环境中执行相同的仅解码序列：拆分、标准化、填充、解码 UTF-8 和解析 JSON。使用您可以检查和控制的任何环境，默认情况下使用非敏感数据。

两条路径都不会验证真实性或授权调用者。读取有效负载形状后，转到服务的可信验证程序和日志以进行加密和策略决策。产生漂亮的 JSON 的命令已经完成了格式化任务，而不是安全判断。