接口提示认证失败，把JWT放进解码器却能看到用户名，这两件事并不矛盾。常见签名JWT的前两段是可读取的编码内容，谁都可能构造出相似的JSON。XunL JWT解码工具提供Header、Payload、声明时间和签名核对入口，适合帮助理解令牌结构；服务端是否接受，仍要由完整认证规则决定。
先认清三段内容，再讨论是否可信
常见的JWS紧凑形式用点号分开Header、Payload和签名。Header通常包含算法等信息，Payload放置声明，签名用于核对内容与密钥之间的关系。这里介绍的是该工具面对的常见签名形式，并不是说全部JWT都只有这一种封装。规范背景与声明定义可查阅RFC 7519。
Base64URL是一种编码表达，不是把内容变成只有收件人才能看懂的加密。不要因为令牌看起来是一长串字符，就把密码或不该暴露的资料放进Payload。排查文章或公开工单时，使用专门的演示令牌，避免把正在使用的登录凭证粘到截图里。
先用教学声明理解时间，再核对实际错误
可以把下面这段JSON作为阅读Payload的教学示例：
{"sub":"demo-user","exp":1700000000}sub用于表示主体，exp表示到期时间，采用秒的时间尺度。这段内容没有提供可用签名，也不是登录凭证。1700000000对应2023年11月14日22:13:20 UTC，因此在本文发布时已经是过去的时刻。若误把十三位毫秒数放进需要秒的声明里，看到的时间就可能远离预期。
- 使用演示或测试环境令牌，粘贴到输入区；工具可处理常见Bearer前缀。
- 先查看Header与Payload是否能够解析，再读exp、iat、nbf等存在的声明；字段缺失也应如实记录。
- 如需核对签名，按令牌算法与测试环境资料选择对应密钥或公钥，检查编码方式是否一致。
- 回到认证服务日志，核对发行者、受众、时钟与业务权限等实际拒绝原因。
iat是签发时间，不等同于最晚可使用时间；nbf用于表示在某时刻之前不可接受。工具把时间转成可读形式，有助于发现秒毫秒和时区问题，但展示“未过期”不能替代服务端的完整接受条件。
签名通过之后，还有哪些问题没有回答
一份令牌可能使用正确密钥签名，却是发给另一套应用的，也可能对应已经停用的账户。认证服务还需要按自身约定检查发行者、受众、允许的算法、有效时间和账户状态，再判断当前请求具有什么权限。解码器不会知道全部业务规则，不能把一项绿色提示作为登录失败的最终裁决。
反过来，验签失败也不必立刻认定服务器出错。测试与生产环境的密钥可能不同，复制过程中可能丢失字符，密钥编码选项也可能与实际资料不一致。先保留错误类型与输入来源，在有权限的测试环境核对；不要为了得到“通过”去修改令牌内容或随意切换算法。
排查材料可以记录令牌类型、出现问题的请求时间、解析到的声明名称以及服务端错误类别。正式凭证和密钥应按原有安全方式管理，不应随着普通工单流转。问题解决后，也要验证权限边界，而不仅是某个页面能否再次打开。
JWT排查常见问题
能看见Payload，是否说明JWT已经泄密？
可读取的Payload是常见签名JWT的正常特征。真正需要注意的是其中放了什么，以及完整令牌是否被不该持有的人获得。编码本身没有提供内容保密，应由系统设计决定哪些信息可以携带。
本地时间显示比服务端晚八小时，令牌一定提前到期了吗？
不一定，先把两边换成同一时刻表示再比较。UTC和北京时间的时钟文字不同，但可以指向同一时间点。若统一后仍有差异，再检查字段单位、设备时钟和认证服务允许的时间误差。
个人微信：ssevening
