深入理解JWT：原理、优缺点及使用场景-艾林博客 - 技术交流与经验分享的个人博客

在现代Web开发中，用户身份认证是一个极为重要的环节。随着应用架构逐渐趋向分布式，传统的会话认证逐渐暴露出种种不足，而**JWT（JSON Web Token）**作为一种基于Token的认证机制，凭借其轻量化、跨语言等特点，迅速成为开发者的首选。

本文将深入解析JWT的工作原理、结构组成、优缺点及其常见的使用场景，帮助您全面了解JWT并在实际项目中正确地使用它。

一、什么是JWT？

JWT（JSON Web Token）是一种基于JSON格式的令牌（Token），它是一种开放标准（RFC 7519），用于在各方之间安全地传递信息。JWT通常用于认证和授权场景中。

JWT的核心思想是：将用户身份信息通过数字签名加密后生成一个令牌，客户端携带该令牌与服务器交互，完成认证和授权操作。

二、JWT的结构

JWT由三部分组成，每部分之间用.分隔，完整的JWT格式如下：

Header.Payload.Signature

1. Header（头部）

Header 包含两部分信息：

类型（typ）：固定为 "JWT"。
算法（alg）：声明使用的签名算法，如 HMAC SHA256 或 RSA。

示例：

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

Header 使用 Base64 编码后可能长成这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

2. Payload（载荷）

Payload 是JWT的主体部分，包含需要传递的用户信息（Claims），它通常分为以下三类：

Registered Claims（标准声明）：如 iss（签发者）、exp（过期时间）、sub（主题）、aud（受众）。
Public Claims（公共声明）：自定义的公共信息，需避免冲突。
Private Claims（私有声明）：双方约定的信息。

示例 Payload：

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

Payload 使用 Base64 编码后可能长成这样：

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjM5MzIyfQ

3. Signature（签名）

签名用于验证JWT的完整性，确保Token未被篡改。签名的生成公式如下：

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

生成的签名示例：

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

最终得到的JWT完整格式如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjM5MzIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

三、JWT的工作流程

用户登录：用户通过用户名和密码向服务器发起登录请求。
服务器生成JWT：
- 验证用户身份后，服务器使用预定义的密钥（Secret）创建JWT。
- JWT中包含用户数据及过期时间。
客户端存储JWT：
- 客户端（例如浏览器或移动端）将JWT存储在LocalStorage或HTTP Only Cookie中。
客户端携带JWT访问资源：
- 客户端每次向服务器发送请求时，在请求头的 Authorization 字段中携带JWT：
```
Authorization: Bearer <JWT>
```
服务器验证JWT：
- 服务器使用密钥验证JWT的合法性。
- 验证通过则返回资源，验证失败则返回 401 Unauthorized。