目录
引言
什么是JWT？
JWT的结构
1. Header（头部）
2. Payload（载荷）
3. Signature（签名）
JWT的工作原理
1. 签发（Issuance）
2. 传输（Transmission）
3. 验证（Verification）
JWT的主要使用场景
1. 身份认证
2. 信息交换
3. 单点登录（SSO）
JWT的优势
使用JWT的安全注意事项
1. 密钥管理
2. 令牌过期
3. 敏感信息保护
4. 存储方式
5. 令牌撤销
结语
引言
在当今的Web开发和微服务架构中，认证与授权是一个核心话题。随着前后端分离、移动应用以及分布式系统的普及，传统的基于Session的认证方式逐渐显露出其局限性——服务器需要维护状态、难以水平扩展、跨域问题复杂。这时，一种轻量级、自包含的认证方案走进了开发者的视野：JWT（JSON Web Token）。
JWT并不是一个新概念，它于2015年成为IETF的RFC 7519标准，至今已被广泛应用于各种现代应用中。本文将带您全面了解JWT的结构、工作原理、使用场景以及在实际项目中如何安全地使用它。
什么是JWT？
JWT（JSON Web Token）是一种开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间以JSON对象的形式安全地传输信息。由于信息是经过数字签名的，因此可以被验证和信任。
简单来说，JWT就是一个包含了用户身份信息和元数据的加密字符串，客户端在每次请求时携带它，服务器通过验证签名即可确认用户身份，而无需在服务器端存储会话数据。
JWT的结构
一个JWT由三部分组成，用点号.分隔，格式如下：
xxxxx.yyyyy.zzzzz
这三部分分别是：
1. Header（头部）
Header通常由两部分组成：令牌的类型（即JWT）和使用的签名算法，例如HMAC SHA256或RSA。
{
"alg": "HS256",
"typ": "JWT"
}
这个JSON对象会被Base64Url编码，形成JWT的第一部分。
2. Payload（载荷）
Payload包含要传递的声明（claims）。声明是关于实体（通常是用户）和其他数据的陈述。例如：
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622
}
这里的sub是主题（用户ID），name是用户名，iat是签发时间，exp是过期时间。同样，Payload也会被Base64Url编码，形成JWT的第二部分。
注意：Payload默认是Base64Url编码，并非加密，因此不应存放敏感信息（如密码），任何人只要拿到JWT就可以解码查看。
3. Signature（签名）
签名是将Header和Payload组合后，使用指定算法和密钥计算出的哈希值。它的作用是确保JWT在传输过程中没有被篡改。
以HS256算法为例，签名的生成方式为：
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
签名保证了JWT的完整性：任何对Header或Payload的修改都会导致签名验证失败。
最终，将这三部分用点连接，就得到了完整的JWT字符串。
JWT的工作原理
JWT的工作流程可以分为三个步骤：签发、传输、验证。
1. 签发（Issuance）
用户通过用户名密码登录成功后，服务器（认证中心）创建一个JWT，其中包含用户的身份信息（如用户ID、角色）以及过期时间，并用服务器的密钥对其进行签名。然后，服务器将这个JWT返回给客户端。
2. 传输（Transmission）
客户端接收到JWT后，需要将其妥善保存。后续每次向服务器请求受保护的资源时，客户端需要在请求中携带这个JWT。常见的方式有两种：
-
放在HTTP Header的Authorization字段中，格式为：Bearer <token>
-
放在Cookie中（建议使用HttpOnly Cookie）
3. 验证（Verification）
服务器收到请求后，从请求中提取JWT，然后：
-
使用相同的密钥验证签名，确保JWT未被篡改。
-
检查JWT中的exp（过期时间）等声明，确保令牌仍然有效。
-
如果验证通过，服务器可以从JWT的Payload中获取用户信息，进行后续的业务处理（如授权）。
由于JWT本身包含了所有必要信息，服务器无需查询数据库或会话存储，这种机制称为无状态认证。
JWT的主要使用场景
1. 身份认证
这是JWT最常用的场景。用户登录后，后续的每个请求都携带JWT，服务端通过验证JWT来识别用户身份。适用于RESTful API、单页应用（SPA）、移动App等。
2. 信息交换
JWT可以在不同服务之间安全地传递用户信息。例如，在微服务架构中，API网关可以将用户信息放在JWT中转发给下游服务，下游服务验证签名后即可信任该信息，无需再调用认证中心。
3. 单点登录（SSO）
JWT的跨域特性使其非常适合SSO场景。用户在一个系统登录后，获得的JWT可以在多个相互信任的应用中使用，实现一次登录、多处访问。
JWT的优势
-
无状态：服务器不需要存储会话数据，便于水平扩展，适合微服务和分布式部署。
-
自包含：JWT中直接包含了用户信息，减少了后续查询数据库的次数，提高了性能。
-
跨域支持：由于JWT通常放在HTTP Header中，可以轻松应对跨域请求，不受Cookie同源策略的限制。
-
安全性：通过签名机制保证数据完整性，防止篡改；配合HTTPS传输，可有效防止中间人攻击。
-
标准化：遵循RFC 7519标准，有丰富的语言支持（Java、Python、Node.js、Go等）。
使用JWT的安全注意事项
尽管JWT有很多优点，但如果使用不当，也会引入安全风险。以下是一些必须关注的点：
1. 密钥管理
密钥是JWT安全的基石。对于对称算法（如HS256），密钥必须严格保密，不应硬编码在代码中或提交到版本库。建议通过环境变量、配置中心或密钥管理服务（KMS）来管理。
2. 令牌过期
JWT一旦签发，在过期前都是有效的。因此，过期时间（exp）应设置得足够短（例如15分钟到2小时），以减少令牌被盗用后的风险窗口。对于需要长期保持登录的应用，可以配合刷新令牌（Refresh Token）机制来获取新的JWT。
3. 敏感信息保护
不要在JWT的Payload中存放密码、手机号等敏感信息，因为Payload只是Base64编码，并非加密。如果确实需要传输敏感数据，应考虑对JWT进行加密（JWE）或使用其他安全方案。
4. 存储方式
客户端如何存储JWT直接影响其安全性：
-
localStorage/sessionStorage：容易受到XSS攻击，恶意脚本可窃取令牌。
-
Cookie（HttpOnly + Secure + SameSite）：可防御XSS，但需防范CSRF。通过设置SameSite=Strict或使用CSRF Token可以缓解CSRF风险。
建议：Web应用优先考虑HttpOnly Cookie，移动端使用系统安全存储（如iOS Keychain、Android Keystore）。
5. 令牌撤销
由于JWT是无状态的，服务器无法主动使一个已签发的令牌失效。当用户注销、修改密码或检测到异常时，需要一种机制来吊销令牌。常见做法是维护一个黑名单（如Redis），存储已注销但未过期的令牌标识，验证时检查是否在黑名单中。
结语
JWT作为一种轻量级的认证和信息交换标准，在现代应用开发中扮演着重要角色。它解决了传统Session认证的诸多痛点，使得构建可扩展、跨平台的系统变得更加容易。然而，JWT并非万能钥匙，正确理解其工作原理、安全边界，并结合实际场景选择合适的存储方式和防护措施，才能真正发挥它的优势。
希望通过本文，您对JWT有了更全面、深入的认识。在接下来的项目中，不妨尝试使用JWT来优化您的认证流程，但请务必牢记：安全无小事，设计需谨慎。
