身份验证和授权这两件事，在早期的单体 Web 应用里并不算复杂：登录成功，会话里记一笔，后续请求拿 Cookie 来对一下。但一旦进入微服务架构，事情会突然变得拧巴——用户请求可能要穿过网关、经过四五个服务，每个服务都想确认“你是谁、能干什么”，总不能每次调用都回会话中心查一次。JSON Web Token（JWT）就是在这个背景下被推到台前的主流方案之一，它把身份信息直接编进一段自包含、带签名的令牌里，服务端拿到就能验，不需要集中式会话存储。这篇文章不会做成枯燥的规范宣读，我会把 JWT 的结构、签名选型、认证链路实操和那些文档里不会写的坑一次性讲透。无论你是刚开始接触鉴权体系的新手，还是已经在项目里踩过 JWT 坑的后端工程师，都可以在里边找到对应的解决方案。
1. 为什么无状态认证成了微服务标配：JWT 的定位分析
1.1 Session 模式在分布式环境里卡在了哪里
传统的基于 Session 的认证流程是这样的：用户在登录页提交账号密码，服务端校验通过后，在内存里创建一个会话对象，同时把会话 ID 写进 Cookie 返回给浏览器。用户之后每一次请求，浏览器自动带上 Cookie，服务端根据会话 ID 找到对应的 Session，再判断用户是否登录、有什么权限。
这个模型在单机部署的时候非常顺畅，逻辑简单，性能也可控。但只要服务开始横向扩展，问题马上浮出水面。第一个问题是会话复制：如果部署了两台应用服务器，用户在 A 机器登录，下一次请求被负载均衡分发到 B 机器，B 机器没有这个 Session，用户就莫名其妙被踢出去。于是团队只能引入会话粘滞（让同一用户的请求固定落到同一台机器），或者做 Session 共享，把会话数据挪到独立存储里。
第二个问题是存储压力。Session 是保存在内存中的，每个用户在活跃期间都占一块内存，用户量一上去，内存占用会非常可观。即使把 Session 外置到缓存中间件，也只是把压力换了个地方，缓存集群本身又变成一个新的瓶颈点和高危单点。更麻烦的是，微服务架构下每个业务服务都可能独立部署、独立扩缩容，让它们共享同一套会话数据，不仅耦合度高，还很容易把认证中心打成瓶颈。
第三个问题是跨域认证。现在的应用形态早就不是“一个 Web 站点”这么简单了，前端 PC 端、手机 H5、小程序、后台管理端往往是多个域名。Cookie 在跨域场景下有很多限制，Session ID 的传递、维护成本都会增加。种种因素叠加，开发者开始寻找一种“不需要在服务端保存会话状态”的认证协议，这正好给 JWT 留出了舞台。
1.2 JWT 靠什么赢得选型
JWT 的核心思想是“把状态装进令牌里”。用户登录成功之后，服务端生成一个经过签名的 JSON Web Token。这个 Token 本身就可以携带用户的身份标识、角色权限、过期时间等数据。服务端之后收到请求时，只需要验证 Token 的签名，确认它没有被篡改，同时检查过期时间，就能放行。
这种做法的好处，用大白话说就是“认签不认人”——服务端不记得谁是谁，只认这段签名是否由信得过的私密密钥生成。它的优势在分布式环境里非常明显：
- 无状态：服务端不需要专门保存会话数据，扩容缩容都不需要同步会话，新节点上线即可服务。
- 自包含：Token 里已经包含必要的用户信息，业务服务可以直接从中读取，省掉一次用户信息查询。
- 可移植：JWT 是一个开放标准，不同语言、不同平台都有成熟的实现库，服务间传递和跨端使用都很方便。
- 天然防篡改：只要算法和密钥管理得当，Token 的任何改动都会导致验签失败。
不过“无状态”也有它的代价，后面我会专门讲到注销失效、Token 泄露等现实问题。核心结论是：JWT 从来不是银弹，而是个“合适场景下很香、选型不当会很难受”的组件。理解它的设计逻辑，比追着最新框架跑更重要。
2. JWT 三段结构全解析：Header、Payload、Signature 里都有什么
一个标准 JWT 长什么样？它是一串紧凑的字符串，格式大致是：xxxxx.yyyyy.zzzzz。三段之间用英文句点分隔。如果拿到一个在线解码工具，或者自己写几行代码解码，你会看到每一段都是经过 Base64URL 编码的 JSON 数据。
2.1 Header：算法声明与类型标识
第一段是 Header，通常长这样：
{ "alg": "HS256", "typ": "JWT" }alg字段声明了后面签名部分使用的算法；typ字段是类型标识，绝大多数情况下固定是JWT。Header 里也可以扩展其它业务字段，但实际项目里我很少往里加东西，保持干净更利于排查。
很多初学者会忽略一个细节：Header 里的alg不光是一句“声明”，验签时算法选择会直接受到它的影响，这也是后面要讲到的“算法混淆攻击”的源头。如果你用的 JWT 库在解析时默认信任 Header 里的算法名，那等于把“用哪种方式验签”的决定权交给了攻击者，这是很危险的设计。
2.2 Payload：核心 Claims 的分类与安全边界
第二段是 Payload，承载的是 Claims，也就是关于实体（通常是用户）和附加数据的声明。JWT 规范把 Claims 分成了三类：
- Registered claims：规范预定义的字段，比如
iss（签发者）、sub（主题）、aud（接收方）、exp（过期时间）、iat（签发时间）、nbf（生效时间）。这些字段名是标准的，工具库普遍能自动识别，因此强烈建议按规范用。 - Public claims：自定义字段，但为了避免冲突，一般建议用 URI 命名或在专门机构注册，日常项目里使用频率不高。
- Private claims：项目自定义的业务字段，比如
userId、role、nickname这类。
实际开发里，我见过许多团队把 Payload 当成万能口袋，什么数据都往里塞。这里必须给一个明确警告：JWT 的内容虽然防篡改，但默认是不加密的，任何人都能通过 Base64URL 解码直接看到内容。把密码、身份证号、银行卡号、手机验证码这类敏感信息放进 Payload，等于把隐私明文贴在门口。若确实有加密展示的需求，正确做法是选用 JWE 规范，而不是在 JWT 里硬塞敏感数据。
关于sub字段，我建议只放用户的稳定唯一标识，比如数据库主键或全局用户 ID。不要放手机号、邮箱这类可变信息，也不要放用户的完整对象结构，因为 Payload 的体积会随着字段数量膨胀，每次请求都要带着它走一趟。
2.3 Signature：到底把哪段内容签了进去
第三段是 Signature。签名过程并不复杂，把前两段编码后的字符串用句点拼起来，然后使用 Header 里声明的算法，用密钥对这个拼接串进行签名，最后再做一次 Base64URL。
用伪代码表达大概是这样：
const signingInput = `${encodedHeader}.${encodedPayload}`; const signature = HMAC_SHA256(signingInput, secretKey);签名的意义在于完整性校验。只要 Payload 或者 Header 被任何人改动过，验签时重新计算出的签名就会不一样，服务端就能拒掉这条请求。这也是 JWT 能被当作身份凭证使用的基础。
这里要特别提一下 Base64URL 和普通 Base64 的区别：JWT 用的编码会把+换成-，把/换成_，并且去掉末尾的=填充字符。这样做的目的是让 Token 可以安全地出现在 URL、请求头和 Cookie 里，不会因为特殊字符造成传输歧义。以前有同事手工调试时用普通 Base64 去解码 JWT，结果怎么都对不上，其实只要弄清楚编码变体，问题瞬间就解释了。
解析时还有一个小细节值得留意：很多库返回的exp、iat是秒级时间戳，而不是毫秒。如果你拿 JavaScript 的Date.now()去比较，得到的值是毫秒，必须先除以 1000 再比较，否则会在某些边界场景出现“刚签发就过期”的错觉。
3. HS256 还是 RS256？JWT 签名算法选型实操
3.1 对称与非对称：一把钥匙和两把钥匙的区别
JWT 签名算法大致分两个阵营：对称算法和非对称算法，分别需要不同的密钥管理思路。对称算法代表是 HS256（HMAC with SHA-256），它只有一个密钥，签名和验签都用同一把钥匙。这个场景很好类比：就像家里的大门，锁和进门都是用同一把钥匙，方便，但要是钥匙丢了，谁捡到都能进。
非对称算法代表是 RS256（RSA with SHA-256）和 ES256（ECDSA with SHA-256）。它使用一对密钥：私钥负责签名，只能由签发方持有；公钥负责验签，可以放心分发给各个消费方。类比的话更像是公章和验章：私章只有发证机构有，大家手里只有验真伪的章，验真伪不需要也不应该拿到私章。
3.2 按架构场景选择算法的具体建议
选择算法没有绝对正确答案，关键看你对密钥的管控能力和架构形态。
如果只有一个认证服务和一套 API，所有验签方都是你完全掌控的后端服务，用 HS256 会非常简洁，生成和验证都只需一个共享密钥，性能也优于非对称方案。
如果是微服务架构，或者有第三方、前端参与验签，我强烈建议 RS256 或 ES256。认证中心用私钥签发，各业务服务只保存公钥，即使某个业务服务被攻破，攻击者拿到的也只是公钥，无法伪造合法 Token。公钥还可以集中放在配置中心或网关层，换签密钥时各业务服务不需要跟着改，运维成本比 HS256 低。
这里我建议用一个表格把常见选型场景收敛一下：
| 架构形态 | 推荐算法 | 原因 |
|---|---|---|
| 单体应用、单一后端 | HS256 | 实现简单，性能好，密钥只在一处 |
| 自有微服务集群 | RS256 / ES256 | 私钥集中在认证服务，业务服务只持公钥 |
| 跨团队、跨组织调用 | RS256 / ES256 | 公钥可公开分发，私钥不出授权方 |
| 第三方或前端参与验签 | RS256 / ES256 | 防止对称密钥在多个不可信节点间扩散 |
ES256 是目前很受青睐的曲线签名方案，它的密钥更短、验算很快，在一些性能敏感场景下优势明显。缺点是能讲清楚 ECDSA 的开发者相对少，如果团队不熟，选 RS256 更稳妥。我的话会建议：大团队、复杂架构优先 RS256/ES256，小项目、闭环服务 HS256 也能用，但密钥要妥善保管。
3.3 容易被忽视的算法安全细节
这里必须展开讲一个真实存在的攻击面：算法混淆攻击。某些 JWT 库在验签时会直接信任 Header 里的alg字段，攻击者可以把alg改成none，让服务端认为该 Token 不需要签名；也可以把 RS256 改成 HS256，诱导服务端使用公钥作为 HMAC 的对称密钥去验签——如果公钥是已知的，攻击者就能用这个公钥生成“合法”签名的 Token。
防范方法是：校验算法白名单。验签代码里显式指定“我只接受 RS256”，任何其它算法的 Token 直接拒绝；同时把alg: none的 Token 直接视为非法。这件事我认为怎么强调都不为过，正是因为它隐蔽，才更容易在代码评审中被漏掉。
另一个容易被忽略的细节是密钥强度。HS256 如果用了很短的字符串私钥，暴力破解风险会显著上升。对称密钥至少要满足随机性足够强、长度不小于 32 字节的要求，否则真是“形同裸奔”。非对称密钥的位数同样不能图省事，RSA 至少 2048 位起步，低于这个标准就该直接淘汰。
4. 从登录到鉴权全流程实操：JWT 怎么发、怎么验、怎么续
这一节我会把完整的认证链路拆开讲：登录时怎么发 Token、请求进来时怎么验、Token 过期之后怎么续。
4.1 登录颁发 Token：关键参数这样设置
典型的登录接口逻辑是：校验用户名密码，查用户资料，然后生成 JWT 返回给前端。伪代码可以这样写：
// 登录成功 const payload = { sub: user.id, role: user.role, iss: "auth-service", aud: "api-service", iat: Math.floor(Date.now() / 1000), exp: Math.floor(Date.now() / 1000) + 7200 }; const token = authLib.sign(payload, privateKey, { algorithm: "RS256" });这里有几个参数值得展开：
sub是主题字段，规范要求是用户的唯一标识，不要写用户昵称、邮箱这种可能变化的信息。iat是签发时间，exp是过期时间。过期时间必须显式设置，否则 Token 永远不会失效，等于把院子门长期敞开。iss和aud分别代表签发者与接收方，在服务较多的系统里，这两个字段能有效避免“A 服务签发的 Token 被 B 服务当作自己的凭证”这种串用问题。exp的粒度建议按需定。前后端交互的场景我一般给 1-2 小时，内部服务间调用的 Token 可以给到 10-30 分钟。
Token 生成之后，通过接口返回给前端。前端需要把 Token 保存在安全位置，并在每次请求的 Authorization 头里带上。格式通常是Authorization: Bearer <token>，这是一种事实上的行业标准，几乎所有框架都有现成的解析中间件支持这个格式。
4.2 服务端校验中间件：至少要做五件事
服务端拿到 Token 后的校验流程，看起来只是一行“验签”，实际要考虑的事情至少有五件：
- 解析 Token：把三段结构拆解出来。
- 验证签名：用预期算法和密钥重新计算签名，和 Token 携带的签名比对。
- 验证过期时间：当前时间必须早于
exp，晚于exp直接 401。 - 验证签发者和接收方：确认
iss、aud符合当前服务配置。 - 提取必要信息：把 Payload 里的用户信息挂到请求上下文里，供后续接口使用。
代码逻辑大致如下：
// 请求中间件 const rawToken = extractTokenFromHeader(req); const decoded = authLib.verify(rawToken, publicKey, { algorithms: ["RS256"], issuer: "auth-service", audience: "api-service" }); req.user = { id: decoded.sub, role: decoded.role };这里必须强调两件事：一是algorithms参数要显式列出允许的算法，不能缺省；二是不要把验签失败的错误吞掉，要能区分是过期、签名错误还是 Token 格式错误，这直接决定返回给客户端的是 401 还是 400。
此外，中间件还要考虑“这个 Token 对应的用户是否还存在、角色是否还是原来的角色”。JWT 是把信息固定下来的，用户被删了、被禁用、角色被降级，Token 在理论上仍然有效。要解决这类即时生效问题，最常见的做法是在关键业务里做轻量二次校验，或者引入 Token 版本号。
4.3 Refresh Token 刷新与主动失效设计
Access Token 过期时间设计得短，用户体验就会差：每隔两小时就得重新登录一次。设计得长，安全风险又高：Token 一旦泄露，攻击者有很长的利用窗口。现在的主流做法是引入 Refresh Token 机制：
- Access Token：短生命周期，比如 15 分钟到 2 小时，用于访问受保护资源。
- Refresh Token：长生命周期，比如 7 天到 30 天，只用于换取新的 Access Token，平时不随业务请求携带。
- 刷新接口：拿着 Refresh Token 来换新的 Access Token（顺带把 Refresh Token 也换掉，这叫轮换）。
Refresh Token 因为作用单一，且生命周期长，更需要小心保存。服务端可以给它做一个简单的存根记录（比如哈希值和过期时间），存储在独立的缓存里。这样既保留了“无状态 JWT”的优势，又能在必要时对 Refresh Token 做吊销处理——发现异常就删掉这个存根，强迫客户端重新登录。
接入刷新机制后，整个链路会变成：
- 客户端持 Access Token 调用业务接口。
- 业务接口发现 Access Token 过期，返回 401。
- 客户端拿着 Refresh Token 调用刷新接口，拿到新的 Access Token 和新的 Refresh Token。
- 客户端用新 Access Token 继续请求。
这里有件事很容易被忽略：Access Token 的过期判断不能只依赖exp字段，还要考虑跳表问题。比如两台服务器时间不完全一致，或者客户端时钟偏差大，可能导致 Token 提前过期或延迟过期。多数 JWT 库会让你配置一个“过期容忍时间窗口”（leeway），一般按 30 到 60 秒设置即可。
5. JWT 从开发到上线的常见问题排查实录
这一节是整篇里我想重点写透的部分。很多文章讲完原理就结束了，但实际项目里真正让人头疼的，往往是那些不起眼的小坑。
5.1 过期时间与服务器时钟偏差导致的失败
现象：Token 明明没过期，客户端却间歇性收到 401。排查方向：先看服务器时间是否同步。容器环境、自建机房经常出现服务器时间差，如果签发 Token 的机器时间超前、验签的机器时间滞后，两边对“现在”的定义不一致，Token 就会莫名其妙地无法通过。
处理办法：给验签配置一个小的 leeway；同时确保集群全局时间统一，最直接的方式是部署时间同步服务并监控时钟偏差。我在实际项目里就没少吃这个亏，上线前一切正常，上线后隔三差五有用户反馈登录掉线，最后排查结论是某个节点的时钟快了十几秒。
5.2 密钥泄露和轮换：如何止血
密钥泄露是 JWT 体系里最可怕的事故之一。一旦私钥或对称密钥泄露，攻击者可以合法地签发任意身份 Token。
常规的止血策略是：立刻换密钥，同时把所有已签发的 Token 强制作废。操作上可以给 JWT 增加一个版本号或jti（JWT ID）字段，服务端维护一个“当前有效版本”的配置。验签时发现版本不对就拒绝。这个做法成本低，不需要把所有在线用户踢下线，而是让旧 Token 在下一个请求自然失效。
另一个建议是：不要把私钥硬编码进代码库，更不要提交到版本仓库。私钥应该放在密钥管理服务、环境变量或专门的配置中心里，并且定期轮换。哪怕暂时没有自动化轮换，设置一个季度或半年一次的轮换提醒，也比一把钥匙用三年强。
5.3 “算法混淆”攻击：这是真实存在的坑
前面讲算法安全时已经提过，这个坑在真实攻击案例里出现过不止一次。攻击手法往往是这样：拿到一个 JWT，把 Header 里的alg从RS256改成HS256，服务端如果直接信任alg字段，就会用 HS256 验签，而很多实现会把 RS256 对应的公钥当作 HS256 的对称密钥。如果公钥是公开的，攻击者等同于拿到了验签密钥。
修复方式说穿了很简单：验签时显式指定算法白名单，拒绝alg: none的 Token，对算法不一致的请求直接返回错误。只要在框架层面固化这个规则，整个攻击面就关掉了。
还有一个细节：即使你用了算法白名单，也需要在签名验证通过之后再做一次“Token 结构合理性”检查。比如exp字段是否存在、格式是否为整数、sub是否为空。有些库在缺少这些字段时不会报错，只是把对象原样返回，这会让业务层拿到一个“看似合法却什么都没表达”的身份。
5.4 注销后 Token 仍有效：怎么优雅处理
无状态 JWT 的天生缺陷就是“不可吊销”。用户点了退出登录，服务端拿到的还是那个合法的 Token，在过期前它依然能访问接口。不同场景有不同的解法：
- 增加 Token 版本号或
jti，服务端维护一个黑名单，注销时把对应jti扔进去，验签后查一下黑名单即可。 - 对敏感操作做二次校验，比如修改密码、支付等高危接口不走纯 Token 鉴权，加验随机码或 OTP。
- 配合 Refresh Token 存根机制：注销时删除 Refresh Token 存根，同时要求客户端丢弃本地 Access Token，让 Access Token 自然到期。
没有绝对完美的方案，实际项目通常是组合使用。我的经验是：不要把注销设计得太重，搞清楚核心诉求是“立刻禁止继续访问”还是“防止下次继续登录”，两者侧重点完全不同。前者必须上黑名单或版本号，后者只需要回收 Refresh Token。
5.5 Token 体积膨胀与网关性能问题
JWT 体积是很多人低估的问题。如果 Payload 塞了太多自定义字段，一个 Token 很容易超过 1KB 甚至 2KB，每次请求都要带着它过网关、打日志、做验签，网络和 CPU 都会有可感知的开销。
排查思路是：看看 Token 平均长度、网关验签耗时和日志字节数，如果明显偏高，第一步是砍 Payload，只留必要字段；第二步是把过期容忍时间、公钥缓存等参数调到位；第三步是在网关侧增加验签结果缓存，对同一 Token 在短时间内沿用验签结果，避免每个请求都执行完整 RSA/ECDSA 运算。
下表汇总了我遇到的典型问题、现象和优先级建议：
| 问题 | 典型现象 | 处理优先级 |
|---|---|---|
| Token 被截获后滥用 | 异常 IP 登录，访问量异常 | 高 |
| exp 缺失导致永不失效 | 删除用户后仍能访问 | 高 |
| 算法混淆 | 攻击者可伪造合法 Token | 高 |
| 时间不同步 | 间歇性 401 | 中 |
| Payload 过大 | 请求延迟、日志膨胀 | 中 |
| 注销不生效 | 退出后 Token 仍可用 | 中 |
最后再分享一点我自己的经验：接手 JWT 相关项目时，不要一开始就急着写代码，先花半天时间把“谁负责签发、谁负责验签、密钥放在哪里、Token 多久过期、注销怎么做”这五个问题想清楚。这五个问题想透了，JWT 方案基本不会跑偏。真的踩过几次坑之后你会明白，JWT 本身并不复杂，复杂的永远是它周边的工程问题和管理细节。希望这篇文章能让你少走几步弯路，把时间花在真正重要的业务逻辑上。
