深度解析 JWT：从 RFC 原理到 NestJS 实战与架构权衡

作者：NEXT06日期：2026/2/18

1. 引言

HTTP 协议本质上是无状态（Stateless）的。在早期的单体应用时代，为了识别用户身份，我们通常依赖 Session-Cookie 机制：服务端在内存或数据库中存储 Session 数据，客户端浏览器通过 Cookie 携带 Session ID。

然而，随着微服务架构和分布式系统的兴起，这种有状态（Stateful）的机制暴露出了明显的弊端：Session 数据需要在集群节点间同步（Session Sticky 或 Session Replication），这极大地限制了系统的水平扩展能力（Horizontal Scaling）。

为了解决这一痛点，JSON Web Token（JWT）应运而生。作为一种轻量级、自包含的身份验证标准，JWT 已成为现代 Web 应用——特别是前后端分离架构与微服务架构中——主流的身份认证解决方案。本文将从原理剖析、NestJS 实战、架构权衡及高频面试考点四个维度，带你全面深入理解 JWT。

2. 什么是 JWT

JWT（JSON Web Token）是基于开放标准 RFC 7519 定义的一种紧凑且自包含的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。

核心特性：

  • 紧凑（Compact） ：体积小，可以通过 URL 参数、POST 参数或 HTTP Header 发送。
  • 自包含（Self-contained） ：Payload 中包含了用户认证所需的所有信息，避免了多次查询数据库。

主要应用场景：

  1. 身份认证（Authorization） ：这是最常见的使用场景。一旦用户登录，后续请求将包含 JWT，允许用户访问该令牌允许的路由、服务和资源。
  2. 信息交换（Information Exchange） ：利用签名机制，确保发送者的身份是合法的，且传输的内容未被篡改。

3. JWT 的解剖学：原理详解

一个标准的 JWT 字符串由三部分组成，通过点（.）分隔：Header(请求头).Payload（载荷）.Signature（签名信息）。

3.1 Header（头部）

Header 通常包含两部分信息：令牌的类型（即 JWT）和所使用的签名算法（如 HMAC SHA256 或 RSA），一般会有多种算法，如果开发者无选择，那么默认是HMAC SHA256算法。

JSON

1{
2  "alg": "HS256",
3  "typ": "JWT"
4}
5

该 JSON 被 Base64Url 编码后，构成 JWT 的第一部分。

3.2 Payload（负载）

Payload 包含声明（Claims），即关于实体（通常是用户）和其他数据的声明。声明分为三类：

  1. Registered Claims（注册声明） ：一组预定义的、建议使用的权利声明，如：
    • iss (Issuer): 签发者
    • exp (Expiration Time): 过期时间
    • sub (Subject): 主题（通常是用户ID）
    • aud (Audience): 受众
  2. Public Claims（公共声明） ：可以由使用 JWT 的人随意定义。
  3. Private Claims（私有声明） ：用于在同意使用这些定义的各方之间共享信息，如 userId、role 等。

架构师警示：
Payload 仅仅是进行了 Base64Url 编码（Encoding） ，而非 加密（Encryption） 。
这意味着，任何截获 Token 的人都可以通过 Base64 解码看到 Payload 中的明文内容。因此，严禁在 Payload 中存储密码、手机号等敏感信息。

3.3 Signature（签名）

签名是 JWT 安全性的核心。它是对前两部分（编码后的 Header 和 Payload）进行签名，以防止数据被篡改。

生成签名的公式如下（以 HMAC SHA256 为例）：

Code

1HMACSHA256(
2  base64UrlEncode(header) + "." + base64UrlEncode(payload),
3  secret
4)
5

原理解析：
服务端持有一个密钥（Secret），该密钥绝不能泄露给客户端。当服务端收到 Token 时，会使用同样的算法和密钥重新计算签名。如果计算出的签名与 Token 中的 Signature 一致，说明 Token 是由合法的服务端签发，且 Payload 中的内容未被篡改（完整性校验）。

4. 实战：基于 NestJS 实现 JWT 认证

NestJS 是 Node.js 生态中优秀的企业级框架。下面演示如何使用 @nestjs/jwt 和 @nestjs/passport 实现标准的 JWT 认证流程。

4.1 依赖安装

Bash

1npm install --save @nestjs/passport passport @nestjs/jwt passport-jwt
2npm install --save-dev @types/passport-jwt
3

4.2 Module 配置

在 AuthModule 中注册 JwtModule，配置密钥和过期时间。

TypeScript

1// auth.module.ts
2import { Module } from '@nestjs/common';
3import { JwtModule } from '@nestjs/jwt';
4import { PassportModule } from '@nestjs/passport';
5import { AuthService } from './auth.service';
6import { JwtStrategy } from './jwt.strategy';
7
8@Module({
9  imports: [
10    PassportModule,
11    JwtModule.register({
12      secret: 'YOUR_SECRET_KEY', // 生产环境请使用环境变量
13      signOptions: { expiresIn: '60m' }, // Token 有效期
14    }),
15  ],
16  providers: [AuthService, JwtStrategy],
17  exports: [AuthService],
18})
19export class AuthModule {}
20

4.3 Service 层：签发 Token

实现登录逻辑，验证用户信息通过后，生成 JWT。

TypeScript

1// auth.service.ts
2import { Injectable } from '@nestjs/common';
3import { JwtService } from '@nestjs/jwt';
4
5@Injectable()
6export class AuthService {
7  constructor(private readonly jwtService: JwtService) {}
8
9  async login(user: any) {
10    const payload = { username: user.username, sub: user.userId };
11    return {
12      access_token: this.jwtService.sign(payload),
13    };
14  }
15}
16

4.4 Strategy 实现：解析 Token

编写策略类，用于解析请求头中的 Bearer Token 并进行验证。

TypeScript

1// jwt.strategy.ts
2import { ExtractJwt, Strategy } from 'passport-jwt';
3import { PassportStrategy } from '@nestjs/passport';
4import { Injectable } from '@nestjs/common';
5
6@Injectable()
7export class JwtStrategy extends PassportStrategy(Strategy) {
8  constructor() {
9    super({
10      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
11      ignoreExpiration: false, // 拒绝过期 Token
12      secretOrKey: 'YOUR_SECRET_KEY', // 需与 Module 中配置一致
13    });
14  }
15
16  async validate(payload: any) {
17    // passport 会自动把返回值注入到 request.user 中
18    return { userId: payload.sub, username: payload.username };
19  }
20}
21

4.5 Controller 使用：路由保护

TypeScript

1// app.controller.ts
2import { Controller, Get, UseGuards, Request } from '@nestjs/common';
3import { AuthGuard } from '@nestjs/passport';
4
5@Controller('profile')
6export class ProfileController {
7  @UseGuards(AuthGuard('jwt'))
8  @Get()
9  getProfile(@Request() req) {
10    return req.user; // 这里是通过 JwtStrategy.validate 返回的数据
11  }
12}
13

5. 深度分析：JWT 的优缺点与架构权衡

优点

  1. 无状态与水平扩展（Stateless & Scalability） ：服务端不需要存储 Session 信息，完全消除了 Session 同步问题，非常适合微服务和分布式架构。
  2. 跨域友好：不依赖 Cookie（尽管可以结合 Cookie 使用），在 CORS 场景下处理更为简单，且天然适配移动端（iOS/Android）开发。
  3. 性能：在不涉及黑名单机制的前提下，验证 Token 只需要 CPU 计算签名，无需查询数据库，减少了 I/O 开销。

缺点与挑战

  1. 令牌体积：JWT 包含了 Payload 信息，相比仅存储 ID 的 Cookie，其体积更大，这会增加每次 HTTP 请求的 Header 大小，影响流量。
  2. 撤销难题（Revocation） ：这是 JWT 最大 的痛点。JWT 一旦签发，在有效期内始终有效。服务端无法像 Session 那样直接删除服务器端数据来强制用户下线。

6. 面试高频考点与解决方案（进阶）

在面试中，仅仅展示如何生成 JWT 是远远不够的，面试官更关注安全性与工程化挑战。

问题 1：JWT 安全吗？如何防范攻击？

  • XSS（跨站脚本攻击） ：如果将 JWT 存储在 localStorage 或 sessionStorage，恶意 JS 脚本可以轻松读取 Token。
    • 解决方案：建议将 Token 存储在标记为 HttpOnly 的 Cookie 中，这样 JS 无法读取。
  • CSRF（跨站请求伪造） ：如果使用 Cookie 存储 Token，则会面临 CSRF 风险。
    • 解决方案：使用 SameSite=Strict 属性，或配合 CSRF Token 防御。如果坚持存储在 localStorage 并通过 Authorization Header 发送，则天然免疫 CSRF，但需重点防范 XSS。
  • 中间人攻击：由于 Header 和 Payload 是明文编码。
    • 解决方案：必须强制全站使用 HTTPS。

问题 2：如何实现注销（Logout）或强制下线？

既然 JWT 是无状态的，如何实现“踢人下线”？这实际上是无状态与管控性之间的权衡。

  • 方案 A：黑名单机制（Blacklist）
    • 将用户注销或被封禁的 Token ID (jti) 存入 Redis，设置过期时间等于 Token 的剩余有效期。
    • 每次请求验证时，先校验签名，再查询 Redis 是否在黑名单中。
    • 权衡：牺牲了部分“无状态”优势（引入了 Redis 查询），但获得了即时的安全管控。
  • 方案 B：版本号/时间戳控制
    • 在 JWT Payload 中加入 token_version。
    • 在数据库用户表中也存储一个 token_version。
    • 当用户修改密码或注销时，增加数据库中的版本号。
    • 权衡：每次验证都需要查询数据库比对版本号，退化回了 Session 的模式，性能开销大。

问题 3：Token 续签（Refresh Token）机制是如何设计的？

为了解决 JWT 有效期过长不安全、过短体验差的问题，业界标准做法是 双 Token 机制：

  1. Access Token：有效期短（如 15 分钟），用于访问业务接口。
  2. Refresh Token：有效期长（如 7 天），仅用于换取新的 Access Token。

流程设计：

  • 客户端请求接口，若 Access Token 过期，服务端返回 401。
  • 客户端捕获 401，携带 Refresh Token 请求 /refresh 接口。
  • 服务端验证 Refresh Token 合法（且未在黑名单/数据库中被禁用），签发新的 Access Token。
  • 关键点：Refresh Token 通常需要在服务端（数据库）持久化存储，以便管理员可以随时禁用某个 Refresh Token，从而间接实现“撤销”用户的登录状态。

7. 结语

JWT 并不是银弹。它通过牺牲一定的“可控性”换取了“无状态”和“扩展性”。

在架构选型时：

  • 如果你的应用是小型单体，且对即时注销要求极高，传统的 Session 模式可能更简单有效。
  • 如果你的应用是微服务架构，或者需要支持多端登录，JWT 是不二之选。
  • 在构建企业级应用时，切勿盲目追求纯粹的无状态。推荐使用 JWT + Access/Refresh Token 双令牌 + Redis 黑名单 的组合拳，以在安全性、性能和扩展性之间取得最佳平衡。

《深度解析 JWT：从 RFC 原理到 NestJS 实战与架构权衡》 是转载文章，点击查看原文。

上一篇：【Python练习五】Python 正则与网络爬虫实战：专项练习（2道经典练习带你巩固基础——看完包会）

下一篇：Linux camera驱动开发（真正需要做的linux驱动开发）

相关推荐

RTOS核心三剑客：任务、信号量与队列深度解析
牛逍遥2026/2/9

RTOS核心三剑客：任务、信号量与队列深度解析 一、裸机编程的瓶颈：为什么需要RTOS？ 在嵌入式开发中，裸机程序通常采用**超级循环(Super Loop)**结构： void main() { while(1) { read_sensors();// 读取传感器 process_data();// 处理数据 update_display();// 刷新显示 handle_uart();// 串口通信 check_safety();// 安全检测 } } 裸机编程的致命缺陷： 阻塞操作导致响

Objective-C手机验证码短信接口调用流程：创建请求对象并设置报文体
2601_949146532026/2/1

在iOS原生开发中，基于Objective-C对接手机验证码短信接口是账号安全、用户验证场景的核心需求，但新手常因请求对象创建不规范、报文体参数编码错误、请求头配置缺失等问题，导致接口返回405（API ID错误）、407（内容含敏感字符）等异常。本文聚焦objective-c手机验证码短信接口的核心调用流程，拆解创建NSURLRequest请求对象、配置请求头、设置报文体的完整逻辑，提供可直接复用的实战代码，解决参数编码、状态码解析等痛点，帮助开发者高效完成接口对接。 一、Objective

没显卡也能玩！Ollama 本地大模型保姆级入门指南
字节逆旅2026/1/22

如果你想在自己电脑上跑 AI，又不希望数据被大厂拿走，Ollama 绝对是目前最香的选择。不用配复杂的 Python 环境，不用求爷爷告奶奶找 API Key，只要一键安装，就能实现“大模型自由”。不过我的电脑很早就有了python环境了，忘记啥时候安装的，虽然在python方面还是个菜鸟。 1. 怎么安装 直接去 Ollama 官网 下载。有1个多G，先有个心理准备。 第一步： 安装完后，它会躲在右下角任务栏。 第二步： 打开终端（CMD 或 PowerShell），输入下面的命令。这

一个致力于为 C# 程序员提供更佳的编码体验和效率的 Visual Studio 扩展插件
追逐时光者2026/1/14

前言 今天大姚给大家分享一个致力于为 C# 程序员提供更佳的编码体验和效率的 Visual Studio 扩展插件：Codist。 Codist 插件介绍 Codist 是一个使用 .NET 编写、开源免费的 Visual Studio 扩展插件，致力于为 C# 程序员提供更好的编程体验和生产效率。它不仅强化了语法高亮、快速信息提示、导航栏、滚动条和显示质量，还集成了自动版本号更新、括号自动补全、支持高级编辑功能的智能工具栏、代码分析等功能。 支持 Visual Studio 版本 Visu

2026：一名码农的“不靠谱”年度规划
苏渡苇2026/1/6

又到了一年一度列计划的时候，我对着屏幕敲下“2026年度目标”这几个字，感觉就像在代码里写下了一个暂时没有具体实现的接口——定义很美好，实现嘛，有待观察。 一、工作要干得出彩，还得有点新花样 说真的，每年我都告诉自己，今年一定要写出那种能让同事看了忍不住赞叹“妙啊”的代码。但实际情况往往是，我对着三年前自己写的代码陷入沉思：“这真是我写的吗？当时怎么想的？” 新点子倒是不缺，缺的是能让这些点子安全落地还不引起生产事故的魔法。我现在的原则是：每个炫酷的想法，都必须配套一个“搞砸了怎么办”的预案。

基于 YOLOv8 的驾驶员疲劳状态识别系统实战（含完整源码与可视化界面）
我是杰尼2025/12/28

基于 YOLOv8 的驾驶员疲劳状态识别系统实战（含完整源码与可视化界面） 一、项目背景与研究意义 随着汽车保有量的持续增长，疲劳驾驶已成为交通事故的重要诱因之一。据统计，在高速公路和长途驾驶场景中，由于驾驶员长时间保持同一姿态，容易出现注意力下降、反应迟钝、频繁眨眼、打哈欠等疲劳特征，从而显著提升事故风险。 传统的疲劳检测方法多依赖以下方式： 车载方向盘行为分析 心率、脑电等生理传感器 人工巡查与事后分析 这些方法或成本较高，或依赖额外硬件，或难以规模化部署。相比之下，基于计算机视觉的疲劳

基于大衍数构造的稀疏校验矩阵LDPC误码率matlab仿真,对比不同译码迭代次数,码率以及码长
我爱C编程2025/12/19

目录 1.引言 2.算法测试效果 3.算法涉及理论知识概要 4.MATLAB核心程序 5.完整算法代码文件获得 1.引言        基于大衍数的LDPC校验矩阵构造，本质是利用大衍数序列的周期性和互素性，设计具有规则稀疏结构的校验矩阵，兼顾性能与实现复杂度。基于大衍数列构造准循环低密度校验码的方法，该方法利用大衍数列固定项差对应的值单调递增的特点，构造出的校验矩阵具有准循环结构，节省了校验矩阵的存储空间。 2.算法测试效果 3.算法涉及理论知识概要

【产品运营必备】数据分析实战宝典：从入门到精通，驱动业务增长（附相关材料下载）
小飞象—木兮2025/12/11

木木自由，专注更多数据分析，经营分析、财务分析、商业分析、数据治理、数据要素、数据资产干货以及资料分享木木自由·   数据分析·领地在产品迭代与运营增长的赛道上，数据分析早已不是“加分项”，而是驱动决策的“核心引擎”。很多产品、运营人员面对数据时常常陷入困境：看着后台一堆指标无从下手，明明做了活动用户却不买账，想优化产品却找不到具体方向。其实，数据分析的核心并非复杂的公式，而是“立足场景、解决问题”的思维的方法。在此，【数据分析·领地】整理了一套《数据分析实战宝典》，将围绕产品与运营的高频场景，

使用 useSearchParams 同步 URL 和查询参数
mCell2025/12/2

同步至个人站点：useSearchParams 使用 useSearchParams 同步 URL 和查询参数 在开发 React 应用时，我们经常遇到一种场景：用户在搜索框输入关键词，筛选出一个列表，然后希望把这个结果分享给同事。 如果我们将筛选条件仅仅保存在组件的 useState 中，一旦刷新页面或复制链接，这些状态就会丢失，用户看到的只能是初始页面。 为了解决这个问题，我们需要将状态“提升”到 URL 的查询参数（Query Params）中。在 React Router v6 中，u

CSDN创作变现活动！社区镜像或使用视频教程分别单个最高得 80 元，收益上不封顶！
CSDN官方博客2026/2/27

CSDN AI 社区是聚焦 AI 技术产业落地的开发者服务平台（官方入口），核心为创作者搭建技术价值转化桥梁，AI社区涵盖： 镜像市场（社区镜像）、算力市场等模块。 本次推出镜像创作激励活动，以下是方案活动规则、参与要求及激励政策，保障创作者权益与活动有序开展。 一、活动总则 活动时间： 2026年1月1日 - 2026年2月28日 现金奖励： 1、按照官方指定镜像任务创作，单个社区镜像奖励 30-80元现金 ，创作越多可获得现金奖

上一篇：【Python练习五】Python 正则与网络爬虫实战：专项练习（2道经典练习带你巩固基础——看完包会）

下一篇：Linux camera驱动开发（真正需要做的linux驱动开发）

首页编辑器站点地图

本站内容在 CC BY-SA 4.0 协议下发布

Copyright © 2026 XYZ博客