JWT Token 如何解析？

JWTJSON Web Token是前后端分离、微服务架构中最主流的身份认证方案之一凭借紧凑、自包含的特性被广泛应用于接口鉴权、用户会话、跨域认证等场景。很多开发者只停留在 “拿 Token 请求接口” 的使用层面并不清楚 JWT 的内部结构与完整解析逻辑甚至误以为 Token 内容是加密的。本文将从结构原理、手动解析、代码实现、安全校验四个维度完整讲解 JWT Token 的解析全过程。一、解析前提理解 JWT 的三段式结构解析 JWT 的核心前提是先搞懂它的标准组成。一个合法的 JWT 是由英文句号.分隔的三段 Base64URL 编码字符串格式固定为Header.Payload.Signature分别对应头部、载荷、签名三部分。1. Header头部头部是描述 JWT 元数据的 JSON 对象通常包含两个核心字段alg签名算法常见值为 HS256HMAC-SHA256、RS256RSA-SHA256typ令牌类型标准值固定为JWT原始 JSON 示例{ alg: HS256, typ: JWT }对该 JSON 执行Base64URL 编码就得到了 JWT 的第一段字符串。2. Payload载荷载荷是存放业务数据的 JSON 对象也是我们解析后真正要读取的内容。标准规范定义了 7 个推荐声明字段Claimiss令牌签发者exp过期时间Unix 时间戳格式sub令牌主题aud令牌受众nbf生效时间在此时间前令牌不可用iat签发时间jtiJWT 唯一标识除标准字段外可自由添加业务字段比如userId、role等。 原始 JSON 示例{ sub: user_auth, userId: 10086, role: admin, exp: 1750000000 }同样经过Base64URL 编码后得到 JWT 的第二段字符串。重要提醒Base64URL 是编码格式而非加密算法任何人拿到 Token 都可以反向解码出载荷明文。绝对不能在 Payload 中存放密码、密钥、身份证号等敏感信息。3. Signature签名签名是 JWT 安全性的核心作用是防止 Token 内容被篡改。生成逻辑分为三步将编码后的 Header 和 Payload 用.拼接成完整字符串使用 Header 中指定的算法配合服务端密钥secret对拼接字符串执行签名运算将运算结果做 Base64URL 编码得到 JWT 的第三段签名以最常用的 HS256 算法为例签名公式为HMACSHA256(base64UrlEncode(header) . base64UrlEncode(payload), secret)二、JWT 解析的本质解码 ≠ 完整解析很多开发者对 “解析” 存在误解需要先明确两个概念的区别单纯解码仅对前两段做 Base64URL 反解拿到 JSON 明文。任何人拿到 Token 都能完成不验证合法性不能用于鉴权。完整解析格式校验 内容解码 签名验证 业务规则校验这才是服务端鉴权场景下的规范流程。一个标准的 JWT 完整解析流程应当包含四步按.拆分三段字符串校验格式是否合法对 Header、Payload 分别做 Base64URL 解码转换为 JSON 对象使用相同算法和服务端密钥重新计算前两段的签名与 Token 第三段对比一致则证明未被篡改校验exp过期时间、nbf生效时间、iss签发者等业务字段是否符合要求三、实操演示手动解析一个 JWT我们用一个真实 Token 演示手动解码的完整过程示例 TokeneyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyX2F1dGgiLCJ1c2VySWQiOjEwMDg2LCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3NTAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c步骤 1拆分三段内容按.分割字符串得到三个独立部分Header 编码eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9Payload 编码eyJzdWIiOiJ1c2VyX2F1dGgiLCJ1c2VySWQiOjEwMDg2LCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3NTAwMDAwMDB9Signature 编码SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c步骤 2解码 HeaderJWT 使用的是 Base64URL与标准 Base64 有三处区别将替换为-将/替换为_移除末尾的填充字符对第一段执行 Base64URL 解码得到原始 Header{ alg: HS256, typ: JWT }步骤 3解码 Payload用同样方式解码第二段即可读取所有业务字段{ sub: user_auth, userId: 10086, role: admin, exp: 1750000000 }此时我们已经能看到完整的载荷内容但这一步仅能用于查看信息绝对不能以此作为权限判断依据—— 因为 Token 可能已经被篡改。步骤 4验证签名核心安全步骤使用 Header 声明的 HS256 算法加上服务端密钥对header_base64.payload_base64重新计算签名再与 Token 第三段做对比两者一致Token 未被篡改内容可信两者不一致Token 被伪造或修改直接拒绝访问四、主流编程语言的 JWT 解析实现实际开发中不建议手动造轮子成熟的开源 JWT 库会自动完成解码、签名校验、时效校验等全套逻辑下面列举三种常用语言的实现方式。1. JavaScript / Node.jsjsonwebtoken 库安装依赖npm install jsonwebtokenconst jwt require(jsonwebtoken); const secret your_server_secret_key; const token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...; // 完整解析 签名时效校验服务端鉴权推荐 try { const decoded jwt.verify(token, secret); console.log(解析结果, decoded); } catch (err) { console.log(Token 无效, err.message); } // 仅解码、不校验签名仅用于前端展示不可鉴权 const payloadOnly jwt.decode(token);2. PythonPyJWT 库安装依赖pip install pyjwtimport jwt secret your_server_secret_key token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... try: # 自动校验签名、过期时间 payload jwt.decode(token, secret, algorithms[HS256]) print(解析结果, payload) except jwt.ExpiredSignatureError: print(Token 已过期) except jwt.InvalidTokenError: print(Token 无效)3. JavaJJWT 库常用 Maven 依赖io.jsonwebtoken:jjwt-api示例代码import io.jsonwebtoken.Claims; import io.jsonwebtoken.Jwts; import io.jsonwebtoken.security.Keys; import javax.crypto.SecretKey; public class JwtParserDemo { public static void main(String[] args) { String secret your_32byte_long_secret_key_here; SecretKey key Keys.hmacShaKeyFor(secret.getBytes()); String token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...; try { Claims claims Jwts.parserBuilder() .setSigningKey(key) .build() .parseClaimsJws(token) .getBody(); System.out.println(userId: claims.get(userId)); } catch (Exception e) { System.out.println(Token 解析失败 e.getMessage()); } } }五、解析 JWT 必须做的 4 项安全校验只解码不校验等于完全放弃鉴权能力。服务端完整解析 JWT 时必须包含以下四项校验签名合法性校验最核心的一步防止攻击者篡改 Payload比如将普通用户角色改为管理员。过期时间exp校验判断当前时间是否超过exp自动拒绝过期 Token。生效时间nbf校验判断当前时间是否早于nbf拒绝尚未生效的 Token。签发者与受众校验多系统、多租户场景下校验iss和aud是否匹配防止 Token 跨系统冒用。六、常见误区与踩坑点误区JWT 是加密的别人看不到内容错误。前两段只是 Base64URL 编码可直接反向解码。敏感信息绝对不能放在 Payload 中。误区前端解析后的数据可以信任错误。前端没有服务端密钥无法验证签名。前端解析结果仅用于页面展示所有权限判断必须以服务端校验为准。踩坑用标准 Base64 解码失败 / 乱码JWT 使用的是 Base64URL 变体直接用普通 Base64 工具解码可能报错。需要先将-换回、_换回/并补全末尾的填充符。踩坑密钥过短导致安全风险HS256 算法建议密钥长度不少于 32 字节过短的密钥极易被暴力破解。七、总结JWT 解析的本质是 “Base64URL 解码 签名验证 业务规则校验” 的组合动作解码门槛极低仅能用于查看内容不具备安全性签名验证是安全核心是服务端鉴权的必要前提实际开发优先使用成熟开源库不要手动实现签名与校验逻辑理解完整的解析原理后你就能避开绝大多数 JWT 使用中的安全漏洞也能更高效地排查 Token 失效、鉴权异常等线上问题。