理解 JWT：三段分别是什么

JWTJSON Web Token是一种把声明claims编码成可传递字符串的方式常见形态是三段用点号连接的 Base64URL 文本。登录成功后前端把一长串xxxxx.yyyyy.zzzzz塞进请求头后端验过就认你是谁。资料里又是签名、加密、鉴权、会话读完仍常不清楚三段各自是干什么的以及它到底防什么。下面按结构拆开讲。一、先说一个具体麻烦接口要求Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMifQ.signature有人以为这段字符串是加密的用户看不懂所以安全。也有人以为只要有 JWT就不用 HTTPS也不用管注销。两种想法都容易出事。JWT 默认常常是可解码可读、靠签名防篡改不是保险箱它也不是完整的会话产品方案。二、核心思路明信片 火漆印简单说常见的签名型 JWT 更像一张明信片1正面写着你的声明谁、什么角色、何时过期——路人可能读得到2火漆印证明「内容没被改过且来自持有密钥的一方」3没火漆或火漆对不上接收方直接拒绝所以 JWT 解决的核心问题是在分布式服务之间传递一份可验证的声明而不必每次都回中心会话库查同一张表具体架构仍可选择有状态黑名单等那是附加设计。三、三段分别是什么标准 JWT 长这样header.payload.signature3.1 Header头部描述元数据常见是 JSON再 Base64URL 编码。{alg:HS256,typ:JWT}上面代码中alg说明签名算法typ说明类型。接收方要按约定算法校验不能盲目信任头部里「声称」的算法而不做白名单约束历史上有算法混淆类问题工程上需按安全实践配置。3.2 Payload载荷放声明。仍是 JSON再 Base64URL 编码。常见字段1sub主体常是用户 id2iat/exp签发时间 / 过期时间3iss/aud签发者 / 受众4自定义声明角色、租户 id 等注意默认不是加密。任何人拿到 token都能解码 payload 看内容。别把密码、身份证号一类敏感数据塞进去。3.3 Signature签名用密钥或私钥对「编码后的 header payload」计算签名防止篡改。直觉公式HMAC 类signature HMAC_SHA256( base64url(header) . base64url(payload), secret )上面结构中改 payload 里的role却不重算合法签名校验就会失败。这就是「火漆印」的作用。四、一次典型校验流程A用户登录认证服务签发 JWTB客户端存储怎么存是另一话题内存、HttpOnly Cookie 等各有取舍C请求业务 API 时带上DAPI 验签名、查exp、查iss/aud等E通过则按声明授权失败则 401验签通过只说明「声明未被篡改且来自可信签发方」。不自动等于「用户此刻仍应拥有全部权限」——权限回收、强制下线需要额外机制。五、JWT 不解决什么1保密性默认可读要保密需走加密型方案JWE或根本别放敏感字段2传输安全仍要 HTTPS否则 token 会被窃听3自动注销未过期的 token在纯无状态模型下仍有效要作废需黑名单、短过期 刷新令牌、或改密钥版本等4替代授权设计有 token ≠ 权限模型正确仍要做对象级授权检查六、实践上几条最小建议1payload 只放必要声明控制体积2设合理exp长会话用刷新令牌旋转而不是超长 access token3校验时核对算法、签发者、受众、过期时间4密钥用足够强度的随机值并支持轮换5日志里不要完整打印 token下面是一个解码示意仅理解结构生产请用成熟库验签。const[h,p]token.split(.)constpayloadJSON.parse(Buffer.from(p,base64url).toString())console.log(payload.sub,payload.exp)上面代码中只演示「payload 可读」。缺少签名校验的代码不能当鉴权。七、常见误区1把 Base64 当成加密编码 ≠ 加密。2存在 localStorage 就以为万事大吉XSS 可偷 token。存储位置要和威胁模型一起选。3算法写none或乱信任 header.alg等于摘掉火漆印。4token 过长塞进一堆权限快照难轮换、难更新也更容易泄露面变大。5401 与 403 分不清token 无效/过期偏 401token 有效但无权限偏 403。八、小结JWT 三段里Header 说明怎么验Payload 装声明Signature 防篡改。它擅长传递可验证的身份与声明不擅长当加密容器也不自动提供完善的会话注销。把三段职责分清后面的安全讨论才有共同语言。完