文章总结： 本文科普JWT身份认证机制，解析其Header、Payload、Signature三段结构及工作原理，对比Session区别，强调Payload非加密、需验签、防篡改等安全要点，并给出短过期、HTTPS、安全存储等可操作建议。 综合评分： 87 文章分类： WEB安全,安全开发,安全意识

---

科普时间 | JWT（JSON Web Token）到底是什么？

原创

火星来的小男孩 火星来的小男孩

篝火信安

2026年9月28日 10:30 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

在分布式 、微服务、前后端分离大行其道的今天，JWT（JSON Web Token） 已经成为身份认证、接口鉴权的主流方案。 本篇文章主要是想把 JWT 讲清楚：它是什么、长什么样、怎么工作以及它和 Session 有什么区别。

JWT （JSON Web Token）是服务器签发的一段带防伪签名的 JSON 令牌。

客户端之后带着它来请求，服务器验证签名后，就能相信里面的信息是服务器自己签发的，没有被篡改。

你可以把它想成一张电子入场手环：上面写着用户 ID、角色、有效期；服务器盖了一个防伪章。别人能看到上面的字，但改不了，因为一改防伪章就对不上。

一. JWT 长什么样？

典型 JWT 长这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

它由三部分组成，用两个点 “.” 分开：

Header.Payload.Signature

也就是：

1. Header：头部，说明用什么算法签名。
2. Payload：载荷，真正携带的数据。
3. Signature：签名，用来防篡改。

这三段通常是 Base64URL 编码。

注意：Base64URL 不是加密，只是一种编码。任何人拿到 JWT，都可以把 Header 和 Payload 解码出来看。

二. 三段分别是什么？

Header

Header 是一个 JSON，通常长这样：

{  "alg":"HS256",  "typ":"JWT"}

alg：签名算法，比如 HS256、RS256。

typ：类型，通常是 JWT。

它被 Base64URL 编码后，成为 JWT 第一段。

Payload

Payload 也是一个 JSON，里面放的是关于用户或令牌的信息。

常见标准字段：

| 字段 | 含义 | | — | — | | sub | Subject，主体，通常是用户 ID | | iss | Issuer，签发者 | | aud | Audience，接收方 | | exp | Expiration Time，过期时间 | | nbf | Not Before，生效时间 | | iat | Issued At，签发时间 | | jti | JWT ID，唯一标识，可用于防重放 |

例如：

{  "sub":"1234567890",  "name":"Alice",  "admin":true,  "iat":1516239022,  "exp":1516242622}

关键点：Payload 不是加密的。

任何人拿到 JWT，都能解码看到这些内容。所以不要放密码、身份证号、银行卡号、手机号等敏感信息。

Signature

签名是 JWT 安全的核心。

服务器生成 JWT 时，会把：

Base64URL(Header) + "." + Base64URL(Payload)

拼起来，然后用密钥和指定算法生成签名。

以 HS256 为例：

HMACSHA256(  base64UrlEncode(header) + "." + base64UrlEncode(payload),  secret)

验证时，服务器用同样方式重新计算签名，再和 JWT 里的签名对比。

如果一致，说明 Header 和 Payload 没被改过。

如果攻击者把 Payload 里的 admin: false 改成 admin: true，签名就会对不上，验证失败。

注意：签名只防篡改，不防偷看。

三. JWT 怎么工作？

以登录认证为例：

1、用户输入用户名和密码。

2、服务器验证通过。

3、服务器生成 JWT，里面包含用户 ID、角色、过期时间等。

4、服务器把 JWT 返回给客户端。

5、客户端保存 JWT。

6、之后每次请求，客户端带上 JWT，通常放在 HTTP 头里：

Authorization: Bearer

7、服务器收到后：

• 拆出 JWT 三段。
• 检查算法是否允许。
• 用密钥或公钥验证签名。
• 检查 exp 是否过期。
• 检查 iss、aud 等字段。
• 全部通过后，才信任 Payload 里的用户信息。

8、服务器根据 Payload 做授权，比如判断是不是管理员。

四. JWT 的特点

JWT 最大的特点：

1、自包含：令牌自己携带了身份和授权所需的信息，不依赖服务端再查一次会话存储。

2、无状态：服务端处理请求时，不依赖之前保存的会话状态。

传统 Session 模式下，服务器要在内存或数据库里保存 Session 数据。

JWT 模式下，用户信息直接放在 JWT 里。服务器验证签名后，就能直接知道用户是谁，不需要每次都查数据库。

好处：

• 服务端不用保存会话，容易横向扩展。
• 适合 API、微服务、分布式系统。
• 跨服务传递身份信息方便。

坏处：

• 令牌一旦签发，在过期前通常一直有效。
• 想立刻注销、封禁、改权限，比较麻烦。
• 令牌会变大，因为携带了数据。
• 如果放错地方，容易被盗。

五. JWT 和 Session 的简单区别

| 对比项 | Session | JWT | | — | — | — | | 状态 | 服务端有状态 | 通常无状态 | | 存储 | 服务端存 Session | 客户端存 JWT | | 验证 | 查 Session 存储 | 验签名 | | 撤销 | 容易，删 Session 即可 | 较难，需要黑名单或短过期 | | 扩展 | 需要共享 Session | 容易水平扩展 |

Session 像“服务端发号牌，自己查表”；JWT 像“服务端发身份证，自己验章”。

六. JWT 安全上必须注意的点

1）JWT 默认不是加密的。

Payload 可以被任何人解码，不要放敏感信息。

2）必须验证签名。

不验证签名，JWT 就等于一张随便伪造的纸。

3）固定算法白名单，禁用 none。

不要相信 JWT Header 里写的算法，服务端只允许自己支持的算法。

4）验证 exp、nbf、iss、aud。

只看签名不够，还要确认令牌没过期、没过早生效、签发者可信、接收方正确。

5）使用强密钥。

HS256 的密钥不能是 secret、123456、password。

密钥要足够长、足够随机，并定期轮换。

6）必须用 HTTPS。

JWT 一旦泄露，攻击者不需要破解签名，直接拿着用就行，直到过期。

7）Access Token 要短命。

比如 5 到 15 分钟。长期会话用 Refresh Token，并支持撤销和旋转。

8）注销和撤销要提前设计。

JWT 无状态，服务端不保存。用户注销后，旧 JWT 在过期前可能仍然有效。

解决方案：短过期、黑名单、令牌版本号、jti 防重放。

9）存储要小心。

放 localStorage 容易被 XSS 偷走。

放 HttpOnly Cookie 能防 XSS 窃取，但要注意 CSRF。

常见做法：Access Token 放内存，Refresh Token 放 HttpOnly + Secure + SameSite Cookie。

10）不要自己手写 JWT 实现。

使用成熟库，并保持更新。

如果您觉得内容还不错的话，请关注我吧！

建议把公众号“篝火信安”设为星标，否则可能就看不到啦！因为公众号现在只对常读和星标的公众号才能展示大图推送。

操作方法：点击公众号页面右上角的【…】，然后点击【设为星标】即可。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：篝火信安 火星来的小男孩 火星来的小男孩《科普时间 | JWT（JSON Web Token）到底是什么？》