什么是 JWT?一文彻底搞懂 JSON Web Token(附 Spring Boot 实战)

视频看了几百小时还迷糊?关注我,几分钟让你秒懂!

你是否经常听到这些词:

  • “我们用 JWT 做登录认证”
  • “前端把 token 放在 Authorization 头里”
  • “JWT 无状态,适合分布式系统”

但你真的理解 JWT 到底是什么?它怎么工作?和 Session 有什么区别? 吗?

今天我们就用 通俗语言 + 图解 + Spring Boot 代码实战,带你从零彻底搞懂 JWT!


🧩 一、一句话解释 JWT

JWT(JSON Web Token)是一种开放标准(RFC 7519),用于在网络应用间安全地传递“声明”(claims)的紧凑、自包含令牌。

简单说:JWT 就是一个加密的字符串,里面包含了用户身份信息,服务器不用查数据库就能验证你是谁!


🔍 二、JWT 长什么样?

一个典型的 JWT 看起来像这样:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ. SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c 

它由 三部分组成,用点 . 分隔

部分说明是否可读
Header(头部)算法 + 类型Base64 可解码
Payload(载荷)用户数据(如 ID、角色、过期时间)Base64 可解码
Signature(签名)用于验证令牌是否被篡改不可逆
注意:JWT 默认是 Base64 编码,不是加密!任何人都能解码看到内容!
🔒 安全靠的是 签名(Signature),防止内容被篡改。

📦 三、三部分详解(附解码示例)

1. Header(头部)

{ "alg": "HS256", "typ": "JWT" } 
  • alg:签名算法(如 HS25 sH A256、RS256)
  • typ:令牌类型,固定为 JWT

2. Payload(载荷)— 存放用户信息的地方!

{ "sub": "1234567890", // 主题(通常是用户ID) "name": "John Doe", "admin": true, "iat": 1516239022, // 签发时间(时间戳) "exp": 1516242622 // 过期时间(重要!) } 
⚠️ 不要在 Payload 里放敏感信息(如密码、手机号)! 因为它是明文(Base64 可解码)!

3. Signature(签名)— 安全的核心!

服务器用 密钥 + 算法Header + Payload 进行签名:

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secretKey ) 
  • 客户端无法伪造签名(不知道 secretKey);
  • 服务器收到 JWT 后,会重新计算签名,比对是否一致;
  • 只要 Payload 被改,签名就失效!

🔄 四、JWT 认证流程(图解)

✅ 整个过程 服务器无需存储 session,真正“无状态”!

⚖️ 五、JWT vs Session(传统方案)

特性JWTSession
存储位置客户端(LocalStorage/Cookie)服务端(内存/Redis)
状态无状态(Stateless)有状态(需维护 session)
扩展性天然支持分布式需共享 session(如 Redis)
安全性依赖签名,防篡改依赖 session ID 随机性
登出难(需黑名单或短期过期)容易(删 session 即可)
传输大小较大(含用户数据)小(只传 session ID)
💡 JWT 适合:API 服务、微服务、移动端
💡 Session 适合:传统 Web 应用、需要强登出控制的系统

💻 六、Spring Boot 实战:手写 JWT 登录

1. 添加依赖

<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </attribute> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-jackson</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency> 

2. JWT 工具类

@Component public class JwtUtil { private String secret = "MySecretKey123!@#"; // 生产环境应配置在 application.yml private long expiration = 86400000; // 24小时 public String generateToken(String userId) { return Jwts.builder() .setSubject(userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expiration)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public String getUserIdFromToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody() .getSubject(); } public boolean validateToken(String token) { try { Jwts.parser().setSigningKey(secret).parseClaimsJws(token); return true; } catch (Exception e) { return false; } } } 

3. 登录接口

@RestController public class AuthController { @Autowired private JwtUtil jwtUtil; @PostMapping("/login") public ResponseEntity<?> login(@RequestBody LoginRequest req) { // 模拟验证账号密码(实际应查数据库) if ("admin".equals(req.getUsername()) && "123456".equals(req.getPassword())) { String token = jwtUtil.generateToken("10001"); return ResponseEntity.ok(Map.of("token", token)); } return ResponseEntity.status(401).body("账号或密码错误"); } } 

4. 拦截器:验证 JWT

public class JwtInterceptor implements HandlerInterceptor { @Autowired private JwtUtil jwtUtil; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String authHeader = request.getHeader("Authorization"); if (authHeader != null && authHeader.startsWith("Bearer ")) { String token = authHeader.substring(7); if (jwtUtil.validateToken(token)) { // 可将用户ID存入 ThreadLocal 或 Request Attribute return true; } } response.setStatus(401); return false; } } 

注册拦截器:

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/login"); } } 

⚠️ 七、JWT 的致命缺点 & 注意事项

❌ 1. 无法主动登出(除非用黑名单)

  • JWT 一旦签发,在过期前一直有效;
  • 即使用户点击“退出”,旧 token 仍可使用;
  • 解决方案
    • 设置较短过期时间(如 15 分钟)+ 刷新令牌(Refresh Token);
    • 维护一个 Redis 黑名单,记录已登出的 token。

❌ 2. Payload 不是加密的!

  • 所有人都能解码看到内容;
  • 永远不要放密码、身份证号等敏感信息!

❌ 3. 密钥泄露 = 全盘崩溃

  • 如果 secretKey 泄露,攻击者可伪造任意用户 token;
  • 必须严格保管密钥!

✅ 最佳实践建议:

项目建议
过期时间Access Token 15~30 分钟,配合 Refresh Token
存储位置Web 用 HttpOnly Cookie(防 XSS),App 用安全存储
传输协议必须 HTTPS
密钥管理用配置中心或环境变量,不要硬编码

🎯 总结

  • JWT = Header + Payload + Signature
  • 自包含、无状态、适合分布式
  • 不是加密,而是签名防篡改
  • 无法主动登出是最大短板
  • Spring Boot 集成简单,但要注意安全细节

掌握 JWT,你就掌握了现代 API 认证的“通行证”!


视频看了几百小时还迷糊?关注我,几分钟让你秒懂!

Read more

BILIVE常见问题解决方案:从安装到运行的全方位排错指南

BILIVE常见问题解决方案:从安装到运行的全方位排错指南 【免费下载链接】bilive极快的B站直播录制、自动切片、自动渲染弹幕以及字幕并投稿至B站,兼容超低配置机器。 项目地址: https://gitcode.com/gh_mirrors/bi/bilive BILIVE是一款功能强大的B站直播录制工具,能够实现7x24小时无人监守录制、渲染弹幕、识别字幕、自动切片、自动上传等功能,且兼容超低配置机器。本文将为您提供从安装到运行过程中的常见问题解决方案,帮助您快速排查并解决使用过程中遇到的各种难题。 一、安装阶段常见问题及解决方法 1.1 克隆项目失败 问题描述:执行git clone --recurse-submodules https://gitcode.com/gh_mirrors/bi/bilive命令时,出现克隆失败或子模块拉取不完整的情况。 解决方法: * 检查网络连接是否正常,确保能够访问GitCode仓库。 * 如果网络不稳定,可以分两步进行:先克隆主项目git clone https://gitcode.

了解ASR(自动语音识别)和模型Whisper

ASR是自动语音识别技术,现代端到端的主流ASR架构为: 音频 → [预处理 → 神经网络编码 → 解码] → 文本                ↑                                           ↑            信号处理                          深度学习 Whisper 是由 OpenAI 于 2022 年发布的开源语音识别模型。它是一个基于 Transformer 架构的端到端模型,具有以下核心特点:多任务模型、多语言支持、多种格式、强鲁棒性和无需微调开箱即用。 一、ASR 音频输入与预处理一般通过ffmpeg与VAD配合完成 1、特征提取与编码 现在的ASR通常使用声学特征直接输入神经网络。 常见的声学特征有以下四种,但是现在一般直接使用神经网络自动学习特征,例如Conformer编码器就是神经网络组成的。 * MFCC(梅尔频率倒谱系数):13-40维 * 梅尔频谱(Mel-Spectrogram):80-128维   * 滤波器组(Filter Bank):40-80维 * 原

[源力觉醒 创作者计划]_文心一言 4.5开源深度解析:性能狂飙 + 中文专精

[源力觉醒 创作者计划]_文心一言 4.5开源深度解析:性能狂飙 + 中文专精

文章目录 * [源力觉醒 创作者计划]_文心一言 4.5开源深度解析:性能狂飙 + 中文专精 * 一. 部署实战:单卡环境的极速落地 * 1.1 🖥️ 环境配置の手把手教程 📝 * 部署准备:硬件与镜像 * 依赖安装:一行代码搞定 * 1.2 🚀 模型启动の参数与验证 ✅. * 二. 多场景能力验证:从工业到学术 * 2.1 🏥 医疗影像诊断:从模糊影像到病灶定位 * 2.2 🚦 交通流优化:动态拥堵预测与策略设计 * 2.3 🔍 考古文本破译:甲骨文符号的跨学科解读 * 三. 性能优化与问题解决 * 3.1 🚀 性能优化策略:让模型跑得更快 * 3.2 🛠️ 常见错误解决方案 * 四. 与同类模型对比 * 🍬 核心优势对比🍭 * 🍬 对比结论🍭 * 五、

llama.cpp 多环境部署指南:从CPU到CUDA/Metal的高效推理实践

1. 环境准备:从零开始的硬件与软件栈 如果你和我一样,对在本地运行大模型充满好奇,但又不想被复杂的框架和庞大的资源消耗吓退,那 llama.cpp 绝对是你该试试的第一个项目。简单来说,它是一个用 C/C++ 编写的轻量级推理引擎,能把 Hugging Face 上那些动辄几十GB的模型,“瘦身”成几GB的 GGUF 格式文件,然后在你的电脑上——无论是 Mac 的 Apple Silicon 芯片,还是 Windows/Linux 的 CPU 或 NVIDIA GPU——流畅地跑起来。我最初接触它,就是想在不升级显卡的老电脑上体验一下 7B 参数模型的对话能力,结果发现它不仅能在 CPU 上跑,还能充分利用 GPU 加速,效果远超预期。