探索 JWT（JSON Web Token）：原理、结构与实践应用对比-CSDN博客

本文链接：https://blog.csdn.net/cooldream2009/article/details/147846351

前言

在现代 Web 应用和微服务架构中，身份认证是系统安全的第一道防线。传统的 Session-Cookie 认证机制虽仍广泛使用，但在移动端、前后端分离架构和分布式系统中，已经逐渐暴露出种种局限性。此时，一种更为灵活、安全、无状态的身份验证方案应运而生——JSON Web Token（JWT）。

本文将深入介绍 JWT 的组成结构、使用原理以及实际作用，并与 Cookie 和 API Key 进行对比，帮助开发者在不同场景下选择合适的认证机制。

1. 什么是 JWT？

JWT，全称为 JSON Web Token，是一种基于 JSON 的开放标准（RFC 7519），用于在网络应用环境中以紧凑、URL 安全的方式传递声明信息。它最常见的用途是实现用户的身份认证和授权。

JWT 最大的特点在于其自包含（self-contained）：它在一个令牌中封装了用户的基本信息以及有效期等元数据，并且可以通过签名来验证其完整性和可信性。这种方式特别适合无状态的分布式系统架构。

2. JWT 的组成结构详解

JWT 通常由三部分组成，分别是 Header、Payload 和 Signature，中间用英文点号（.）分隔。一个典型的 JWT 看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.  
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvbiBEb2UiLCJhZG1pbiI6dHJ1ZX0.  
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

下面对这三部分进行详细说明。
在这里插入图片描述

2.1 Header（头部）

Header 描述了令牌的类型以及签名所使用的算法。最常见的算法是 HMAC SHA256（对应的算法标识为 HS256），也可以使用 RSA 等非对称加密算法。

例如：

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

Header 会被进行 Base64Url 编码，成为 JWT 的第一部分。

2.2 Payload（负载）

Payload 是 JWT 的核心，包含了令牌要传递的声明（Claims）。声明分为三类：

注册声明（Registered Claims）：如 iss（发行者）、exp（过期时间）、sub（主题）、aud（接收方）等。
公共声明（Public Claims）：定义在 JWT 规范之外但公开使用的声明。
私有声明（Private Claims）：服务端自定义的字段，如用户名、权限角色等。

一个典型的 Payload 结构如下：

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "exp": 1715123456
}

Payload 同样会被 Base64Url 编码，是 JWT 的第二部分。需要注意的是，Payload 虽然被编码了，但未加密，因此不应包含敏感信息。

2.3 Signature（签名）

签名部分用于校验 Header 和 Payload 是否在传输过程中被篡改，同时也用于验证 JWT 的真实性。

签名的生成方式如下：

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

服务端会使用预先定义的密钥（secret）对前两部分进行签名，客户端在接收到 JWT 后，服务端也可以使用相同的密钥验证其合法性。

3. JWT 的实际作用

3.1 身份认证

在 Web 应用中，JWT 最常见的用途是实现用户身份认证。流程如下：

用户使用用户名和密码登录。
服务器验证成功后，生成一个 JWT 并返回给客户端。
客户端保存该 Token（通常放在 localStorage 或 sessionStorage 中）。
之后每次请求，客户端在 HTTP 请求头中加入该 Token：

   Authorization: Bearer <token>

服务器验证 Token，若合法则继续处理请求。

这一过程与传统的 Cookie-Session 模式不同，服务器不需要保存用户的会话状态，实现了真正的无状态认证。
在这里插入图片描述

3.2 信息传递与授权

由于 JWT 可以携带任意声明，除了身份信息外，还可存储用户权限、访问范围等内容。因此，它也可以作为服务间进行权限控制的工具。

在微服务架构中，各服务之间可通过 JWT 来识别请求的发起方并进行权限验证，而不需要依赖中心化的 Session 存储。

4. JWT 与 Cookie、API Key 的比较

为了更清晰地理解 JWT 的优势与适用场景，我们可以将其与 Cookie 和 API Key 这两种传统认证方式进行对比。

4.1 JWT 与 Cookie

Cookie 是 Web 应用中最早用于身份认证和状态管理的机制，配合服务器端的 Session 使用，维持用户登录状态。与之相比，JWT 是无状态的，不依赖服务端存储。

Cookie 的优势在于浏览器支持良好，自动管理，适合传统 Web 应用。但它的缺点在于扩展性差，在分布式环境中需要额外的 Session 同步机制。

JWT 则更适用于前后端分离、移动端、微服务等现代架构。其 Token 由客户端保存和管理，服务端可以通过验证签名确认用户身份，无需存储会话数据。

不过，JWT 也存在劣势：例如，令牌体积较大，不能随意撤销，可能面临存储泄露（如 localStorage 被 XSS 攻击）的风险。

4.2 JWT 与 API Key

API Key 是最简单的认证方式，通常是一个字符串，附加在请求头或 URL 中，用于识别调用方身份。

虽然实现简便，但安全性较低，API Key 一旦泄露就会造成重大风险，而且一般缺乏用户上下文信息和权限控制，无法承载复杂的声明逻辑。

JWT 则是结构化的数据载体，不仅支持用户身份，还可承载权限、过期时间等丰富信息，适合复杂的访问控制需求。

4.3 JWT vs Cookie vs API Key

特性/工具	JWT	Cookie	API Key
用途	身份验证、信息交换	状态管理、会话追踪	简单的身份验证
服务器状态	无状态（Stateless）	有状态（Stateful）	通常无状态
存储位置	客户端（localStorage/sessionStorage）	浏览器自动管理的 Cookie	客户端（代码中或配置中）
自动发送	否（需手动加在 header 中）	是（自动随请求发送）	否（需手动加在 header 或 URL 中）
安全性	中等（需防止泄露和 XSS）	高（可用 HttpOnly、Secure）	低（容易暴露、无过期控制）
适用场景	分布式系统、微服务、SPA	传统 web 应用会话管理	简单的接口访问验证
可扩展性	高（可存多种自定义信息）	中（主要是存 session id）	低（只能做身份验证）