JWT这个缩写后端面试里出现频率快赶上HashMap了。你只要打开招聘软件搜Java后端或者Go后端十有八九会在职位描述里看到它真到了面试现场面试官也爱从“认证怎么做”切入聊着聊着就问你 JWT 结构到底是什么。网上的教程很多但大部分要么只讲三段式编码要么直接甩一个封装好的工具类看完还是不懂为什么这么设计。这篇我按自己的理解把 JWT 拆成三条线来讲它解决了什么问题、它内部长什么样、在真实项目里怎么落地最后再把面试官真正想听的考点串一遍。不管你是准备面试的中级开发者还是正在做登录权限模块想找个顺手方案这篇都值得花十分钟看完。1. JWT到底是什么为什么它让 Session 方案显得笨重1.1 先搞清楚 Session 和 Token 的本质区别要理解 JWT得先回到一个问题HTTP 协议是无状态的。什么意思就是你上次请求是什么样服务器根本记不住每个请求都是“陌生人”。最早大家用 Cookie Session 解决记忆问题用户登录成功后服务器生成一个 sessionId存到自己的内存或者 Redis 里同时把 sessionId 种到浏览器的 Cookie 里。下次请求浏览器自动带上 Cookie服务器拿 sessionId 去自己那边查一下查到就算登录过。这个方案很直观但坑也很明显服务器得保存大量会话数据。你的用户量一上来单机内存顶不住就得做 Session 同步或者把 Session 抽到 Redis。分布式环境下每台服务器都得知道“这个人有没有登录”要么依赖共享存储要么做黏性会话怎么搞都麻烦。Token 的思路反过来了服务器不保存会话用户登录成功后服务器把用户信息、过期时间这些数据按约定格式做成一个凭证字符串发给客户端。客户端每次请求都带上这个字符串服务器只需要校验字符串本身是否合法、是否过期就能断定“这个请求是谁发出来的”。存储压力为零水平扩容轻轻松松。JWT 就是这种 Token 的一种标准化格式。它不是唯一的 Token 方案但绝对是最流行的一种。1.2 JWT 和普通 Token 不是一个东西很多初学者会把“Token”和“JWT”划等号这个是面试里最容易翻车的地方。普通的 Token 可以是一串完全随机的字符串服务端收到后要去数据库或者 Redis 里查这串字符串对应的用户是谁本质上还是“有状态”的只是把 SessionId 换了个名字。而 JWT 是三段式的结构用户信息、过期时间都写在 Token 里面服务端拿到后直接解码就能知道用户是谁不需要再查存储。换句话说普通 Token 是“凭据 服务端查询”JWT 是“凭据 自包含数据 签名校验”。JWT 值钱的地方在于它把数据直接塞进了凭证里同时用签名保证数据没被改过。这一点理解了后面很多面试题都能迎刃而解。1.3 JWT 适合哪些场景不适合哪些场景先说适合的前后端分离项目、移动端 App、微服务之间调用、第三方开放平台授权。这类场景的共同点是客户端类型多、服务端实例多用 Session 做共享会话会非常痛苦JWT 的无状态特性正好踩在点上。不适合的也有如果你的业务要求“管理员能立刻把某个用户踢下线”或者用户改密码后所有旧 Token 必须立刻失效纯 JWT 做起来很难受因为它在过期之前天然是有效的。这时候要么引入黑名单机制要么干脆用回 Session。我说这些是想强调一个观点JWT 不是银弹它是最佳方案和妥协方案的结合体选型的时候一定要看到它的边界。2. JWT 结构拆解Header、Payload、Signature 三段存了什么2.1 先看一个真实 Token 长什么样JWT 看起来就是一长串由点号分隔的字符串分三段格式永远是 xxx.yyy.zzz。随便给你一个真实例子eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c第一段是 Header第二段是 Payload第三段是 Signature。很多人第一反应是“这玩意能不能解密出内容”答案是前两段根本不是加密只是 Base64URL 编码。你随便找个在线解码工具或者用 Python 里 base64 解一下马上能看到明文 JSON。这也是后面安全部分要重点强调的JWT 默认不加密别把手机号身份证塞进去。2.2 Header告诉服务器“我用什么算法签的名”Header 是一个 JSON 对象最常见的两个字段是 alg 和 typ。typ 通常固定是 JWTalg 是签名算法常见的有 HS256、RS256、ES256。举个例子{ alg: HS256, typ: JWT }alg 字段是整个 JWT 安全性的关键。因为在服务端验签的时候必须知道这个 Token 是用什么算法生成的才能用对应的算法重新计算签名。万一服务端没校验算法直接信任客户端传过来的 alg就会出现经典的 algnone 攻击。这部分后面单独聊面试高频。有的 Header 里还会带 kid 字段表示“用哪一把密钥来验签”。这在多密钥轮换、多应用共用一个验证服务时非常有用。不加 kid 的话密钥一换旧 Token 全废线上事故就是这么出的。2.3 Payload真正有用的业务数据都在这Payload 也是一个 JSON 对象用来放用户相关信息和一些标准字段。JWT 规范预定义了一些字段叫 Registered Claims实际项目中经常用到的是这几个字段全称含义subSubject面向的用户一般放用户IDissIssuer签发方比如你的应用名audAudience接收方表示这个 Token 给谁用expExpiration Time过期时间Unix 时间戳nbfNot Before在这个时间之前不可用iatIssued At签发时间jtiJWT IDToken 唯一 ID用于吊销和防重放除了这些标准字段你还能往里放自定义字段比如 userId、userName、role。我在生产项目里通常只放最小必要数据用户ID、用户名、角色其他信息一概不放。因为每次请求都会带上这个 TokenPayload 越大请求头越肥而且这些数据等于是半公开的。2.4 SignatureJWT 防篡改的核心机制Signature 是整个 JWT 的灵魂。它的计算过程可以理解为把 Base64URL 编码后的 Header 和 Payload 用点号拼起来再用 Header 里声明的算法和一把只有服务端知道的密钥对这个字符串做签名。以最常用的 HS256 为例HMACSHA256( base64UrlEncode(header) . base64UrlEncode(payload), secret )计算出来是一段二进制字节再经过 Base64URL 编码拼到前两段后面就成了第三段。验签的时候服务端拿到 Token拆出前两段用同样的 secret 重新算一遍签名然后和 Token 自带的 Signature 做比对。一致就说明前两段内容没被改过。用生活化的类比就是你在支票上填好金额然后盖上银行预留的印鉴。别人可以抄你的支票内容但盖不出你的印鉴。只要印鉴对不上银行就知道这张支票被动过手脚。这就是“防止数据被串改”的底层逻辑。攻击者不知道 secret就算他把 Payload 里的 userId 改成别人的重新编码后的签名也对不上服务端直接拒绝。2.5 HS256 和 RS256对称密钥和非对称密钥的区别这两个算法是面试常客。HS256 是对称算法签名和验签用同一把 secret。优点是计算快、实现简单缺点是 secret 必须在所有需要验签的服务之间共享适合内部系统。RS256 是非对称算法私钥签名公钥验签。签名方持有私钥验签方只要拿到公钥就能校验公钥可以随便分发。第三方开放平台、跨公司服务调用基本首选 RS256因为每个下游服务不需要知道私钥泄密面小得多。代价是计算更慢、Token 也更大。面试时如果被问倒可以补一句“为了防止密钥泄露影响全部服务RS256 在微服务场景下更安全因为验证方即使被拖库拿到的也只是公钥”。这句话很能体现你的架构意识。3. JWT 认证流程从登录到接口放行整条链路到底怎么走3.1 最典型的登录认证流程拆解结合真实项目JWT 最常用在“登录后访问受保护接口”这个场景。完整流程大概分七步用户提交账号密码到登录接口。服务端校验用户名密码通过后生成一个 JWT把用户ID、过期时间、角色等数据放进 Payload。服务端把 JWT 返回给前端前端保存起来。前端每一次请求在 HTTP Header 里带上Authorization: Bearer token。服务端收到请求先取出 Token拆出 Header 和 Payload用密钥重新计算 Signature。签名一致再检查 exp 是否过期检查 nbf 是否已经到了可用时间。全部通过服务端从 Payload 里拿出 userId放行接口逻辑。这里有一个特别容易误解的地方服务端如何知道用户是谁答案就是 Payload 里的 sub 或 userId 字段。因为签名校验通过说明这个 Token 是服务端自己签发的Payload 里的可信的。所以后续接口直接用这个 userId 查业务数据就行不需要再走一遍登录逻辑。3.2 Token 存在哪里最安全前端存储方案对比前端拿到 JWT 后到底放哪里这个问题面试也能问出一堆。常见的三个位置localStorage、sessionStorage、Cookie。localStorage 的优点是好用JavaScript 直接读写缺点是任何 XSS 脚本都能偷走 Token。sessionStorage 差不多但关掉浏览器标签页就没了。Cookie 的好处是可以设为 HttpOnlyJavaScript 读不到能挡掉大部分 XSS 偷 Token 的问题缺点是容易踩 CSRF 的坑需要配合 SameSite 属性。我在项目里的习惯是分场景如果是纯前端项目Access Token 放在内存变量里页面刷新后通过 Refresh Token 再换一次Refresh Token 放在 HttpOnly Cookie 里。如果项目复杂度不高也可以把 Access Token 放 Cookie 并设置 SameSiteLax换取简单。核心原则是能不放 localStorage 就不放XSS 面前 localStorage 等于裸奔。3.3 服务端校验代码演示Java 和 Python 各来一个Java 生态最常用的是 jjwt 库引入依赖后校验代码非常简洁String secret your-256-bit-secret; String token request.getHeader(Authorization).replace(Bearer , ); try { Claims claims Jwts.parserBuilder() .setSigningKey(secret) .build() .parseClaimsJws(token) .getBody(); String userId claims.get(userId, String.class); // 校验通过继续处理业务 } catch (JwtException e) { // 签名错误、Token 被篡改 throw new UnauthorizedException(token invalid); } catch (ExpiredJwtException e) { // 过期 throw new UnauthorizedException(token expired); }Python 用 PyJWT 更简单import jwt try: payload jwt.decode(token, secret, algorithms[HS256]) user_id payload[userId] except jwt.ExpiredSignatureError: # 过期 pass except jwt.InvalidTokenError: # 签名不对或被篡改 pass很多人写代码的时候喜欢自己手写签名逻辑我建议别这么干。成熟的库已经处理好了各种边界情况比如 exp 检测、算法白名单自己造轮子容易漏。面试时如果被问到底层原理能手写 HMAC 计算过程会很加分但生产代码请相信库。3.4 Token 续签的三种主流方案JWT 最大的痛点之一就是过期了怎么办。纯前端项目不可能让用户每 15 分钟重新输入一次密码所以必须实现续签。目前主流的方案有三种第一种是前端拦截 401用 Refresh Token 换新的 Access Token。用户登录时拿到两个 TokenAccess Token 有效期短Refresh Token 有效期长。Access Token 过期后前端拿着 Refresh Token 请求刷新接口换取新的 Access Token。这个方案灵活缺点是要处理并发刷新多个接口同时 401 时不能重复调用刷新接口。第二种是滑动过期。只要用户在有效期内持续操作服务端每次请求都顺带签发一个新的 Token把过期时间往后推。像极了健身房会员到期前一直续卡。缺点也很明显频繁签发新 Token而且一个 Token 可以一直“续命”安全边界很模糊。第三种是双 Token 加 Redis 白名单。Refresh Token 签发给前端之外同时把它的 jti 存到 Redis设置好过期时间。每次刷新时要校验 Redis 里有没有这个 jti。这样一旦用户被踢掉只要删掉 Redis 里的 jtiRefresh Token 立刻作废。这是我个人最推荐的生产级方案兼顾了 JWT 的无状态优势和主动吊销的诉求。4. 面试考点面试官真正想听的其实是这八个问题4.1 高频面试题速查表问题考察点回答要点JWT 和 Session 有什么区别基础认知Session 服务端存储、有状态JWT 客户端存储、无状态、自包含JWT 三段结构是什么基础结构Header、Payload、Signature前两段 Base64URL 编码第三段签名为什么 JWT 能防止数据被篡改原理理解HMAC 签名验签secret 只有服务端知道Payload 改动后签名对不上Token 过期了怎么办工程能力Refresh Token 续签、滑动过期、黑名单如何让 JWT 主动失效工程能力Redis 黑名单、维护 jti、缩短过期时间JWT 安全风险有哪些安全意识algnone、密钥泄露、Payload 明文、XSS 偷 Token为什么要 Access Token Refresh Token架构设计缩短 Access Token 暴露窗口Refresh Token 用于续签Payload 里能放密码吗安全意识不能Base64URL 是编码不是加密这张表基本覆盖了 JWT 方向 80% 的面试问题而且都是能往深里聊的题。面试官只要顺着其中一个问题往下追问你如果没有完整理解很容易露馅。4.2 用一个故事把 JWT 讲清楚面试时不要干巴巴背概念试着用场景把原理串起来。我经常举一个酒店门卡的例子你办入住的时候前台确认你的身份然后给你一张门卡。门卡上写好了你的房号还有一个只有酒店系统能识别的校验信息。你走到房间门口门锁只需要检查门卡上的校验信息和有效期不需要打电话问前台“这个人订过房吗”。这个故事对应到 JWT 上前台是认证服务门卡是 Token房号是 Payload 里的用户ID校验信息是签名门锁是业务服务。门锁不依赖中央系统这就是无状态。如果门卡上写的是“总统套房”但你改成了“员工通道”门锁一校验签名就知道卡被动过直接拒绝。故事讲完再补一句“所以 JWT 解决的是分布式场景下认证凭证的验真问题”面试官对你的印象会很深。4.3 手写一个 JWT 生成与校验的最小实现不少面试官喜欢让候选人现场写 JWT 生成过程。虽然生产环境要用库但手写能证明你真的理解原理。用 Python 演示最直观import base64 import hashlib import hmac import json import time def b64url_encode(data: bytes) - str: return base64.urlsafe_b64encode(data).rstrip(b).decode() def b64url_decode(data: str) - bytes: padding * (-len(data) % 4) return base64.urlsafe_b64decode(data padding) # 1. 构造 Header 和 Payload header {alg: HS256, typ: JWT} payload {userId: 1001, role: admin, exp: int(time.time()) 3600} # 2. 分别做 Base64URL 编码 header_part b64url_encode(json.dumps(header, separators(,, :)).encode()) payload_part b64url_encode(json.dumps(payload, separators(,, :)).encode()) signing_input f{header_part}.{payload_part} # 3. 用 HMAC-SHA256 计算签名 secret bmy-secret-key signature hmac.new(secret, signing_input.encode(), hashlib.sha256).digest() signature_part b64url_encode(signature) # 4. 拼接完整 JWT token f{signing_input}.{signature_part} print(token) # 5. 校验重新计算签名并比对 received token.split(.) received_signature b64url_decode(received[2]) expected_signature hmac.new(secret, f{received[0]}.{received[1]}.encode(), hashlib.sha256).digest() print(hmac.compare_digest(received_signature, expected_signature))这段代码删掉注释也就二十行。面试时写出来比背概念强得多。注意最后那行用了 hmac.compare_digest 而不是直接用这是防时序攻击的习惯写出来也是加分项。4.4 什么话一说出来面试官就觉得你懂概念题谁都背过区分度在于你有没有踩过坑。面试官问完“JWT 好用吗”之后你可以主动补两句第一句JWT 把认证信息从服务端存储转移到了客户端但同时也把吊销问题甩给了自己。Token 在过期前天然有效所以纯 JWT 不等于无状态银弹生产里必须配合短过期时间和刷新机制。第二句Base64URL 不是加密是编码。敏感数据一定不能放 Payload要么把数据放到服务端存储要么用 JWE 做加密 JWT。第三句密钥管理比 Token 本身更重要。HS256 的 secret 一旦泄露攻击者可以自己伪造任意身份的 TokenRS256 的私钥泄露同理。这些话不是教程里抄的是真实项目里被坑出来的。面试官听到这种表述至少知道你上过生产环境。5. 常见坑与安全风险实录这些都是线上踩出来的教训5.1 algnone 漏洞最经典的 JWT 攻击这是 JWT 漏洞总结里出现频率最高的一条。攻击方法很简单把一个合法 Token 的 Header 里 alg 改成 nonePayload 改成自己想要的用户ID然后删掉第三段签名看看服务端会不会放行。有些服务端在验签时完全信任 Header 里的 alg 字段。如果代码里没做算法白名单遇到 none 就直接跳过验签攻击成功。修复也简单验签时明确指定允许的算法不允许 none。用 jjwt 的话可以在 parserBuilder 里显式设置算法Jwts.parserBuilder() .setSigningKey(secret) .setAllowedClockSkewSeconds(60) .build()同时服务端代码里要有一个算法白名单校验比如只接受 HS256。很多库新版本已经默认拒绝 none但如果你用了老版本库或者自己拼字符串解析 Token中招概率极大。这个坑值得反复提醒。5.2 密钥泄露与离线暴力破解HS256 是对称密钥只要 secret 泄露攻击者就能用同一个 secret 伪造任意身份的 Token。更隐蔽的风险是如果 secret 太短攻击者拿到一个合法 Token 后完全可以在本地离线跑字典暴力猜解 secret。曾经有人把 secret 设成 “secret”几秒钟就被跑出来。所以生产环境对 secret 的要求是足够长、足够随机定期轮换。而且密钥要放进配置中心或者环境变量绝对不能提交到代码仓库。我见过一次事故就是开发把 secret 写死在配置文件里结果代码仓库泄露所有 Token 全部要重签线上服务瘫痪了一个小时。5.3 Token 失效和注销困境JWT 过期之前服务端怎么让它立刻失效答案是不好办。我把这块单独拎出来说因为很多人用 JWT 做登录后某天产品提了个需求“管理员要能踢用户下线”结果发现 JWT 根本踢不掉。常规解法是引入黑名单机制每个 Token 生成时带一个唯一的 jti写进 RedisTTL 设成和 Token 剩余有效期一致。正常情况不查一旦需要踢人把 jti 加进黑名单下次请求校验时先查一下黑名单。这相当于给无状态凭证加了一个“临时状态”牺牲了一点无状态性但换来了可控性。如果你的业务里踢人是常态操作比如后台管理系统频繁调整权限那 JWT 未必是最好的选择。这点在技术选型时就要想清楚而不是上线之后补窟窿。5.4 续签与多端登录的坑刷新 Token 也有坑。最典型的是并发刷新Access Token 过期后前端同时发 5 个请求全部 401然后每个请求都触发一次刷新Refresh Token 被重复使用。有些服务端规定 Refresh Token 只能换一次新的换出来旧的立刻作废那并发刷新直接连环失败。解决思路有两种前端把刷新请求做成单例401 后只发一个刷新请求其他请求排队等待新 Token服务端允许 Refresh Token 在短时间窗口内重复使用但返回同一个新的 Access Token。多端登录是另一个坑用户在一台手机上退出登录服务端如果只删了本地 Token用户在其他设备上的会话不受影响。要做到“踢掉所有设备”得给每个会话分配独立的 jti退出时把对应 jti 扔进黑名单。不做这一步用户体验就是在 A 设备退出后B 设备还能继续操作然后你会收到一堆“为什么不能退出”的客诉工单。5.5 别把 JWT 当加密用这个坑太常见了。Base64URL 是一种编码不是加密。任何人拿到你的 JWT分解出中间那一段用几行代码就能秒解出原始 JSON。你把手机号、身份证号、家庭地址塞进 Payload等于把这些信息明文送给了所有能看到请求的人。正确做法是Payload 里只放用户ID、角色这种不敏感标识其余信息需要的时候再查接口。如果业务确实要在 Token 里携带敏感数据应该用 JWE加密 JWT而不是普通 JWT。另外前端开发调试工具都会显示请求头如果 Token 里有敏感字段开发的时候截图一贴数据就泄出去了。5.6 第三方登录与 Token Exchange 常见报错诊断现在很多项目接入了第三方授权登录报错里经常出现 token exchange failed 这类信息。除了 JWT 本身还有 OAuth2 协议里的 Token Endpoint 调用失败。最常见的几个原因授权码已过期或已被使用、redirect_uri 和注册的不一致、client_id 或 client_secret 写错、系统时间和服务器时间偏差太大导致 nbf 和 exp 校验失败、网络代理拦截了 Token Endpoint 请求。遇到这类报错我的排查顺序是先看请求参数里授权码是否有效再看 redirect_uri 是否和注册时完全一致然后确认 client 凭证没写错最后检查服务器时间同步。80% 的 exchange 失败都出在这四步。这条经验在接入微信扫码登录、企业微信登录、各类第三方 SSO 时都通用建议大家收藏。结尾关于 JWT我自己的几个体会文章写到这里最后说点个人心得。JWT 从来不是一个“用就完了”的东西它背后的设计哲学是把验证成本从服务端转移给密码学。这本身很优雅但代价就是你必须更谨慎地管理密钥、过期时间、刷新策略。我在实际项目里看到过太多人把 JWT 当成万能钥匙一套方案通吃所有场景结果不是 Token 没法吊销就是续签逻辑写成面条。如果让我给你一个最实用的建议那就是先想清楚“我这个 Token 允不允许在真实业务中被主动作废”再决定要不要用纯 JWT。如果你选了 JWT那就在第一版就把 jti、过期时间、刷新 Token 的 Redis 存储一起做进去不要等上线后被需求追着改。最后分享一个小技巧给生成的 JWT 里固定塞一个 jti即使不用黑名单排查线上问题时也能靠它精确定位到是哪一个客户端、哪一次登录发出去的 Token。这个字段很不起眼关键时刻比什么都好使。 
长河君 · 2026/9/20 20:13:21 · 阅读 1.2k JWT认证核心原理与安全实践：从结构拆解到面试考点全解析
JWT这个缩写后端面试里出现频率快赶上HashMap了。你只要打开招聘软件搜Java后端或者Go后端十有八九会在职位描述里看到它真到了面试现场面试官也爱从“认证怎么做”切入聊着聊着就问你 JWT 结构到底是什么。网上的教程很多但大部分要么只讲三段式编码要么直接甩一个封装好的工具类看完还是不懂为什么这么设计。这篇我按自己的理解把 JWT 拆成三条线来讲它解决了什么问题、它内部长什么样、在真实项目里怎么落地最后再把面试官真正想听的考点串一遍。不管你是准备面试的中级开发者还是正在做登录权限模块想找个顺手方案这篇都值得花十分钟看完。1. JWT到底是什么为什么它让 Session 方案显得笨重1.1 先搞清楚 Session 和 Token 的本质区别要理解 JWT得先回到一个问题HTTP 协议是无状态的。什么意思就是你上次请求是什么样服务器根本记不住每个请求都是“陌生人”。最早大家用 Cookie Session 解决记忆问题用户登录成功后服务器生成一个 sessionId存到自己的内存或者 Redis 里同时把 sessionId 种到浏览器的 Cookie 里。下次请求浏览器自动带上 Cookie服务器拿 sessionId 去自己那边查一下查到就算登录过。这个方案很直观但坑也很明显服务器得保存大量会话数据。你的用户量一上来单机内存顶不住就得做 Session 同步或者把 Session 抽到 Redis。分布式环境下每台服务器都得知道“这个人有没有登录”要么依赖共享存储要么做黏性会话怎么搞都麻烦。Token 的思路反过来了服务器不保存会话用户登录成功后服务器把用户信息、过期时间这些数据按约定格式做成一个凭证字符串发给客户端。客户端每次请求都带上这个字符串服务器只需要校验字符串本身是否合法、是否过期就能断定“这个请求是谁发出来的”。存储压力为零水平扩容轻轻松松。JWT 就是这种 Token 的一种标准化格式。它不是唯一的 Token 方案但绝对是最流行的一种。1.2 JWT 和普通 Token 不是一个东西很多初学者会把“Token”和“JWT”划等号这个是面试里最容易翻车的地方。普通的 Token 可以是一串完全随机的字符串服务端收到后要去数据库或者 Redis 里查这串字符串对应的用户是谁本质上还是“有状态”的只是把 SessionId 换了个名字。而 JWT 是三段式的结构用户信息、过期时间都写在 Token 里面服务端拿到后直接解码就能知道用户是谁不需要再查存储。换句话说普通 Token 是“凭据 服务端查询”JWT 是“凭据 自包含数据 签名校验”。JWT 值钱的地方在于它把数据直接塞进了凭证里同时用签名保证数据没被改过。这一点理解了后面很多面试题都能迎刃而解。1.3 JWT 适合哪些场景不适合哪些场景先说适合的前后端分离项目、移动端 App、微服务之间调用、第三方开放平台授权。这类场景的共同点是客户端类型多、服务端实例多用 Session 做共享会话会非常痛苦JWT 的无状态特性正好踩在点上。不适合的也有如果你的业务要求“管理员能立刻把某个用户踢下线”或者用户改密码后所有旧 Token 必须立刻失效纯 JWT 做起来很难受因为它在过期之前天然是有效的。这时候要么引入黑名单机制要么干脆用回 Session。我说这些是想强调一个观点JWT 不是银弹它是最佳方案和妥协方案的结合体选型的时候一定要看到它的边界。2. JWT 结构拆解Header、Payload、Signature 三段存了什么2.1 先看一个真实 Token 长什么样JWT 看起来就是一长串由点号分隔的字符串分三段格式永远是 xxx.yyy.zzz。随便给你一个真实例子eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c第一段是 Header第二段是 Payload第三段是 Signature。很多人第一反应是“这玩意能不能解密出内容”答案是前两段根本不是加密只是 Base64URL 编码。你随便找个在线解码工具或者用 Python 里 base64 解一下马上能看到明文 JSON。这也是后面安全部分要重点强调的JWT 默认不加密别把手机号身份证塞进去。2.2 Header告诉服务器“我用什么算法签的名”Header 是一个 JSON 对象最常见的两个字段是 alg 和 typ。typ 通常固定是 JWTalg 是签名算法常见的有 HS256、RS256、ES256。举个例子{ alg: HS256, typ: JWT }alg 字段是整个 JWT 安全性的关键。因为在服务端验签的时候必须知道这个 Token 是用什么算法生成的才能用对应的算法重新计算签名。万一服务端没校验算法直接信任客户端传过来的 alg就会出现经典的 algnone 攻击。这部分后面单独聊面试高频。有的 Header 里还会带 kid 字段表示“用哪一把密钥来验签”。这在多密钥轮换、多应用共用一个验证服务时非常有用。不加 kid 的话密钥一换旧 Token 全废线上事故就是这么出的。2.3 Payload真正有用的业务数据都在这Payload 也是一个 JSON 对象用来放用户相关信息和一些标准字段。JWT 规范预定义了一些字段叫 Registered Claims实际项目中经常用到的是这几个字段全称含义subSubject面向的用户一般放用户IDissIssuer签发方比如你的应用名audAudience接收方表示这个 Token 给谁用expExpiration Time过期时间Unix 时间戳nbfNot Before在这个时间之前不可用iatIssued At签发时间jtiJWT IDToken 唯一 ID用于吊销和防重放除了这些标准字段你还能往里放自定义字段比如 userId、userName、role。我在生产项目里通常只放最小必要数据用户ID、用户名、角色其他信息一概不放。因为每次请求都会带上这个 TokenPayload 越大请求头越肥而且这些数据等于是半公开的。2.4 SignatureJWT 防篡改的核心机制Signature 是整个 JWT 的灵魂。它的计算过程可以理解为把 Base64URL 编码后的 Header 和 Payload 用点号拼起来再用 Header 里声明的算法和一把只有服务端知道的密钥对这个字符串做签名。以最常用的 HS256 为例HMACSHA256( base64UrlEncode(header) . base64UrlEncode(payload), secret )计算出来是一段二进制字节再经过 Base64URL 编码拼到前两段后面就成了第三段。验签的时候服务端拿到 Token拆出前两段用同样的 secret 重新算一遍签名然后和 Token 自带的 Signature 做比对。一致就说明前两段内容没被改过。用生活化的类比就是你在支票上填好金额然后盖上银行预留的印鉴。别人可以抄你的支票内容但盖不出你的印鉴。只要印鉴对不上银行就知道这张支票被动过手脚。这就是“防止数据被串改”的底层逻辑。攻击者不知道 secret就算他把 Payload 里的 userId 改成别人的重新编码后的签名也对不上服务端直接拒绝。2.5 HS256 和 RS256对称密钥和非对称密钥的区别这两个算法是面试常客。HS256 是对称算法签名和验签用同一把 secret。优点是计算快、实现简单缺点是 secret 必须在所有需要验签的服务之间共享适合内部系统。RS256 是非对称算法私钥签名公钥验签。签名方持有私钥验签方只要拿到公钥就能校验公钥可以随便分发。第三方开放平台、跨公司服务调用基本首选 RS256因为每个下游服务不需要知道私钥泄密面小得多。代价是计算更慢、Token 也更大。面试时如果被问倒可以补一句“为了防止密钥泄露影响全部服务RS256 在微服务场景下更安全因为验证方即使被拖库拿到的也只是公钥”。这句话很能体现你的架构意识。3. JWT 认证流程从登录到接口放行整条链路到底怎么走3.1 最典型的登录认证流程拆解结合真实项目JWT 最常用在“登录后访问受保护接口”这个场景。完整流程大概分七步用户提交账号密码到登录接口。服务端校验用户名密码通过后生成一个 JWT把用户ID、过期时间、角色等数据放进 Payload。服务端把 JWT 返回给前端前端保存起来。前端每一次请求在 HTTP Header 里带上Authorization: Bearer token。服务端收到请求先取出 Token拆出 Header 和 Payload用密钥重新计算 Signature。签名一致再检查 exp 是否过期检查 nbf 是否已经到了可用时间。全部通过服务端从 Payload 里拿出 userId放行接口逻辑。这里有一个特别容易误解的地方服务端如何知道用户是谁答案就是 Payload 里的 sub 或 userId 字段。因为签名校验通过说明这个 Token 是服务端自己签发的Payload 里的可信的。所以后续接口直接用这个 userId 查业务数据就行不需要再走一遍登录逻辑。3.2 Token 存在哪里最安全前端存储方案对比前端拿到 JWT 后到底放哪里这个问题面试也能问出一堆。常见的三个位置localStorage、sessionStorage、Cookie。localStorage 的优点是好用JavaScript 直接读写缺点是任何 XSS 脚本都能偷走 Token。sessionStorage 差不多但关掉浏览器标签页就没了。Cookie 的好处是可以设为 HttpOnlyJavaScript 读不到能挡掉大部分 XSS 偷 Token 的问题缺点是容易踩 CSRF 的坑需要配合 SameSite 属性。我在项目里的习惯是分场景如果是纯前端项目Access Token 放在内存变量里页面刷新后通过 Refresh Token 再换一次Refresh Token 放在 HttpOnly Cookie 里。如果项目复杂度不高也可以把 Access Token 放 Cookie 并设置 SameSiteLax换取简单。核心原则是能不放 localStorage 就不放XSS 面前 localStorage 等于裸奔。3.3 服务端校验代码演示Java 和 Python 各来一个Java 生态最常用的是 jjwt 库引入依赖后校验代码非常简洁String secret your-256-bit-secret; String token request.getHeader(Authorization).replace(Bearer , ); try { Claims claims Jwts.parserBuilder() .setSigningKey(secret) .build() .parseClaimsJws(token) .getBody(); String userId claims.get(userId, String.class); // 校验通过继续处理业务 } catch (JwtException e) { // 签名错误、Token 被篡改 throw new UnauthorizedException(token invalid); } catch (ExpiredJwtException e) { // 过期 throw new UnauthorizedException(token expired); }Python 用 PyJWT 更简单import jwt try: payload jwt.decode(token, secret, algorithms[HS256]) user_id payload[userId] except jwt.ExpiredSignatureError: # 过期 pass except jwt.InvalidTokenError: # 签名不对或被篡改 pass很多人写代码的时候喜欢自己手写签名逻辑我建议别这么干。成熟的库已经处理好了各种边界情况比如 exp 检测、算法白名单自己造轮子容易漏。面试时如果被问到底层原理能手写 HMAC 计算过程会很加分但生产代码请相信库。3.4 Token 续签的三种主流方案JWT 最大的痛点之一就是过期了怎么办。纯前端项目不可能让用户每 15 分钟重新输入一次密码所以必须实现续签。目前主流的方案有三种第一种是前端拦截 401用 Refresh Token 换新的 Access Token。用户登录时拿到两个 TokenAccess Token 有效期短Refresh Token 有效期长。Access Token 过期后前端拿着 Refresh Token 请求刷新接口换取新的 Access Token。这个方案灵活缺点是要处理并发刷新多个接口同时 401 时不能重复调用刷新接口。第二种是滑动过期。只要用户在有效期内持续操作服务端每次请求都顺带签发一个新的 Token把过期时间往后推。像极了健身房会员到期前一直续卡。缺点也很明显频繁签发新 Token而且一个 Token 可以一直“续命”安全边界很模糊。第三种是双 Token 加 Redis 白名单。Refresh Token 签发给前端之外同时把它的 jti 存到 Redis设置好过期时间。每次刷新时要校验 Redis 里有没有这个 jti。这样一旦用户被踢掉只要删掉 Redis 里的 jtiRefresh Token 立刻作废。这是我个人最推荐的生产级方案兼顾了 JWT 的无状态优势和主动吊销的诉求。4. 面试考点面试官真正想听的其实是这八个问题4.1 高频面试题速查表问题考察点回答要点JWT 和 Session 有什么区别基础认知Session 服务端存储、有状态JWT 客户端存储、无状态、自包含JWT 三段结构是什么基础结构Header、Payload、Signature前两段 Base64URL 编码第三段签名为什么 JWT 能防止数据被篡改原理理解HMAC 签名验签secret 只有服务端知道Payload 改动后签名对不上Token 过期了怎么办工程能力Refresh Token 续签、滑动过期、黑名单如何让 JWT 主动失效工程能力Redis 黑名单、维护 jti、缩短过期时间JWT 安全风险有哪些安全意识algnone、密钥泄露、Payload 明文、XSS 偷 Token为什么要 Access Token Refresh Token架构设计缩短 Access Token 暴露窗口Refresh Token 用于续签Payload 里能放密码吗安全意识不能Base64URL 是编码不是加密这张表基本覆盖了 JWT 方向 80% 的面试问题而且都是能往深里聊的题。面试官只要顺着其中一个问题往下追问你如果没有完整理解很容易露馅。4.2 用一个故事把 JWT 讲清楚面试时不要干巴巴背概念试着用场景把原理串起来。我经常举一个酒店门卡的例子你办入住的时候前台确认你的身份然后给你一张门卡。门卡上写好了你的房号还有一个只有酒店系统能识别的校验信息。你走到房间门口门锁只需要检查门卡上的校验信息和有效期不需要打电话问前台“这个人订过房吗”。这个故事对应到 JWT 上前台是认证服务门卡是 Token房号是 Payload 里的用户ID校验信息是签名门锁是业务服务。门锁不依赖中央系统这就是无状态。如果门卡上写的是“总统套房”但你改成了“员工通道”门锁一校验签名就知道卡被动过直接拒绝。故事讲完再补一句“所以 JWT 解决的是分布式场景下认证凭证的验真问题”面试官对你的印象会很深。4.3 手写一个 JWT 生成与校验的最小实现不少面试官喜欢让候选人现场写 JWT 生成过程。虽然生产环境要用库但手写能证明你真的理解原理。用 Python 演示最直观import base64 import hashlib import hmac import json import time def b64url_encode(data: bytes) - str: return base64.urlsafe_b64encode(data).rstrip(b).decode() def b64url_decode(data: str) - bytes: padding * (-len(data) % 4) return base64.urlsafe_b64decode(data padding) # 1. 构造 Header 和 Payload header {alg: HS256, typ: JWT} payload {userId: 1001, role: admin, exp: int(time.time()) 3600} # 2. 分别做 Base64URL 编码 header_part b64url_encode(json.dumps(header, separators(,, :)).encode()) payload_part b64url_encode(json.dumps(payload, separators(,, :)).encode()) signing_input f{header_part}.{payload_part} # 3. 用 HMAC-SHA256 计算签名 secret bmy-secret-key signature hmac.new(secret, signing_input.encode(), hashlib.sha256).digest() signature_part b64url_encode(signature) # 4. 拼接完整 JWT token f{signing_input}.{signature_part} print(token) # 5. 校验重新计算签名并比对 received token.split(.) received_signature b64url_decode(received[2]) expected_signature hmac.new(secret, f{received[0]}.{received[1]}.encode(), hashlib.sha256).digest() print(hmac.compare_digest(received_signature, expected_signature))这段代码删掉注释也就二十行。面试时写出来比背概念强得多。注意最后那行用了 hmac.compare_digest 而不是直接用这是防时序攻击的习惯写出来也是加分项。4.4 什么话一说出来面试官就觉得你懂概念题谁都背过区分度在于你有没有踩过坑。面试官问完“JWT 好用吗”之后你可以主动补两句第一句JWT 把认证信息从服务端存储转移到了客户端但同时也把吊销问题甩给了自己。Token 在过期前天然有效所以纯 JWT 不等于无状态银弹生产里必须配合短过期时间和刷新机制。第二句Base64URL 不是加密是编码。敏感数据一定不能放 Payload要么把数据放到服务端存储要么用 JWE 做加密 JWT。第三句密钥管理比 Token 本身更重要。HS256 的 secret 一旦泄露攻击者可以自己伪造任意身份的 TokenRS256 的私钥泄露同理。这些话不是教程里抄的是真实项目里被坑出来的。面试官听到这种表述至少知道你上过生产环境。5. 常见坑与安全风险实录这些都是线上踩出来的教训5.1 algnone 漏洞最经典的 JWT 攻击这是 JWT 漏洞总结里出现频率最高的一条。攻击方法很简单把一个合法 Token 的 Header 里 alg 改成 nonePayload 改成自己想要的用户ID然后删掉第三段签名看看服务端会不会放行。有些服务端在验签时完全信任 Header 里的 alg 字段。如果代码里没做算法白名单遇到 none 就直接跳过验签攻击成功。修复也简单验签时明确指定允许的算法不允许 none。用 jjwt 的话可以在 parserBuilder 里显式设置算法Jwts.parserBuilder() .setSigningKey(secret) .setAllowedClockSkewSeconds(60) .build()同时服务端代码里要有一个算法白名单校验比如只接受 HS256。很多库新版本已经默认拒绝 none但如果你用了老版本库或者自己拼字符串解析 Token中招概率极大。这个坑值得反复提醒。5.2 密钥泄露与离线暴力破解HS256 是对称密钥只要 secret 泄露攻击者就能用同一个 secret 伪造任意身份的 Token。更隐蔽的风险是如果 secret 太短攻击者拿到一个合法 Token 后完全可以在本地离线跑字典暴力猜解 secret。曾经有人把 secret 设成 “secret”几秒钟就被跑出来。所以生产环境对 secret 的要求是足够长、足够随机定期轮换。而且密钥要放进配置中心或者环境变量绝对不能提交到代码仓库。我见过一次事故就是开发把 secret 写死在配置文件里结果代码仓库泄露所有 Token 全部要重签线上服务瘫痪了一个小时。5.3 Token 失效和注销困境JWT 过期之前服务端怎么让它立刻失效答案是不好办。我把这块单独拎出来说因为很多人用 JWT 做登录后某天产品提了个需求“管理员要能踢用户下线”结果发现 JWT 根本踢不掉。常规解法是引入黑名单机制每个 Token 生成时带一个唯一的 jti写进 RedisTTL 设成和 Token 剩余有效期一致。正常情况不查一旦需要踢人把 jti 加进黑名单下次请求校验时先查一下黑名单。这相当于给无状态凭证加了一个“临时状态”牺牲了一点无状态性但换来了可控性。如果你的业务里踢人是常态操作比如后台管理系统频繁调整权限那 JWT 未必是最好的选择。这点在技术选型时就要想清楚而不是上线之后补窟窿。5.4 续签与多端登录的坑刷新 Token 也有坑。最典型的是并发刷新Access Token 过期后前端同时发 5 个请求全部 401然后每个请求都触发一次刷新Refresh Token 被重复使用。有些服务端规定 Refresh Token 只能换一次新的换出来旧的立刻作废那并发刷新直接连环失败。解决思路有两种前端把刷新请求做成单例401 后只发一个刷新请求其他请求排队等待新 Token服务端允许 Refresh Token 在短时间窗口内重复使用但返回同一个新的 Access Token。多端登录是另一个坑用户在一台手机上退出登录服务端如果只删了本地 Token用户在其他设备上的会话不受影响。要做到“踢掉所有设备”得给每个会话分配独立的 jti退出时把对应 jti 扔进黑名单。不做这一步用户体验就是在 A 设备退出后B 设备还能继续操作然后你会收到一堆“为什么不能退出”的客诉工单。5.5 别把 JWT 当加密用这个坑太常见了。Base64URL 是一种编码不是加密。任何人拿到你的 JWT分解出中间那一段用几行代码就能秒解出原始 JSON。你把手机号、身份证号、家庭地址塞进 Payload等于把这些信息明文送给了所有能看到请求的人。正确做法是Payload 里只放用户ID、角色这种不敏感标识其余信息需要的时候再查接口。如果业务确实要在 Token 里携带敏感数据应该用 JWE加密 JWT而不是普通 JWT。另外前端开发调试工具都会显示请求头如果 Token 里有敏感字段开发的时候截图一贴数据就泄出去了。5.6 第三方登录与 Token Exchange 常见报错诊断现在很多项目接入了第三方授权登录报错里经常出现 token exchange failed 这类信息。除了 JWT 本身还有 OAuth2 协议里的 Token Endpoint 调用失败。最常见的几个原因授权码已过期或已被使用、redirect_uri 和注册的不一致、client_id 或 client_secret 写错、系统时间和服务器时间偏差太大导致 nbf 和 exp 校验失败、网络代理拦截了 Token Endpoint 请求。遇到这类报错我的排查顺序是先看请求参数里授权码是否有效再看 redirect_uri 是否和注册时完全一致然后确认 client 凭证没写错最后检查服务器时间同步。80% 的 exchange 失败都出在这四步。这条经验在接入微信扫码登录、企业微信登录、各类第三方 SSO 时都通用建议大家收藏。结尾关于 JWT我自己的几个体会文章写到这里最后说点个人心得。JWT 从来不是一个“用就完了”的东西它背后的设计哲学是把验证成本从服务端转移给密码学。这本身很优雅但代价就是你必须更谨慎地管理密钥、过期时间、刷新策略。我在实际项目里看到过太多人把 JWT 当成万能钥匙一套方案通吃所有场景结果不是 Token 没法吊销就是续签逻辑写成面条。如果让我给你一个最实用的建议那就是先想清楚“我这个 Token 允不允许在真实业务中被主动作废”再决定要不要用纯 JWT。如果你选了 JWT那就在第一版就把 jti、过期时间、刷新 Token 的 Redis 存储一起做进去不要等上线后被需求追着改。最后分享一个小技巧给生成的 JWT 里固定塞一个 jti即使不用黑名单排查线上问题时也能靠它精确定位到是哪一个客户端、哪一次登录发出去的 Token。这个字段很不起眼关键时刻比什么都好使。