Base64URL 与 JWT：能解码，不等于能信任
JWT 使用 Base64URL，不是普通 Base64。读懂 payload、签名验证和填充规则。
JWT 有三个 URL 安全部分
常见签名 JWT 由三段组成，中间用点号隔开：header、payload、signature。RFC 7519 把 JWT 定义为紧凑的 URL 安全声明格式，RFC 7515 定义 JWS 紧凑序列化里的 Base64URL 编码。
Base64URL 换了两个字符
Base64URL 沿用 6 位分组思路，但换掉两个字符：+ 变成 -，/ 变成 _。JWT 还会省略末尾的 =。这样 token 放进请求头、URL、表单值时，少了转义问题。
解码不是验证
你可以把 header 和 payload 解出来，查看 iss、sub、aud、exp、scope 这类 JSON 声明。这个动作只是在读文本。它不能证明签发方、接收方、过期时间或签名。服务端必须用正确密钥和算法验证签名或 MAC，之后才能信任声明。
警惕 alg 字段
header 会写算法名，但应用必须自己规定接受哪些算法。看到意外的 alg 值，就应该判定验证失败。不要让 token 替你的系统选择更弱的方法。
排查流程要清楚
先按点号拆分 token。前两段按 Base64URL 解码。工具需要填充时，再按长度规则补等号。读 JSON。然后用签发方密钥验证签名，并检查 issuer、audience、时间声明和业务规则。