JWT通过数字签名实现无状态认证，由Header、Payload、Signature三部分组成，支持跨系统认证；其安全性依赖强密钥、HTTPS传输、短过期时间及敏感信息不存储于载荷，常见风险包括令牌泄露、弱密钥和算法混淆；相比传统Session的有状态管理，JWT无需服务端存储会话，适合分布式架构，但难以主动失效，需结合黑名单或刷新令牌机制；实际应用中应采用Access Token与Refresh Token分离、HttpOnly Cookie存储、全面声明验证等策略以提升安全性。
JWT是一种紧凑且自包含的方式，用于在各方之间安全地传输信息。它通过数字签名确保信息的可信度，常用于实现无状态的用户认证和授权机制。当用户登录成功后，服务器会生成一个JWT并将其发送给客户端，客户端在后续请求中携带此令牌，服务器通过验证令牌的有效性来确认用户身份和权限。
JWT的工作原理可以分解为几个关键步骤。当用户通过用户名和密码成功登录后，认证服务器（或后端服务）会生成一个JWT。这个令牌由三部分组成，用点号（.）分隔：头部（Header）、载荷（Payload）和签名（Signature）。
头部通常包含令牌的类型（JWT）和所使用的签名算法（如HS256或RS256）。载荷则包含了实际的声明（claims），这些声明可以是关于用户的（如用户ID、角色），也可以是关于令牌本身的（如过期时间exp、签发时间iat）。这些声明可以是预定义的（registered claims）、公共的（public claims）或私有的（private claims）。
生成令牌时，头部和载荷会先进行Base64Url编码。然后，将编码后的头部、一个点和编码后的载荷连接起来，使用头部中指定的签名算法，结合一个只有服务器知道的密钥（secret）或私钥，对这个字符串进行签名，生成第三部分——签名。这个签名是JWT安全性的核心，它确保了令牌在传输过程中未被篡改。
服务器将这个完整的JWT发送给客户端，通常作为HTTP响应的一部分。客户端接收到JWT后，将其存储起来，比如存在本地存储（localStorage）或Cookie中。在后续的每个需要认证的请求中，客户端会将这个JWT放在HTTP请求头的
Authorization字段中，格式通常是
Bearer。
当服务器收到带有JWT的请求时，它会执行验证。这个过程包括几个方面：首先，检查令牌的结构是否正确；然后，使用相同的签名算法和密钥，重新计算签名，并与接收到的签名进行比对，以验证令牌的完整性。如果签名不匹配，说明令牌可能被篡改。服务器还会检查令牌的过期时间（
expclaim），确保令牌仍然有效。通过这些步骤，服务器可以在不查询数据库的情况下，快速且安全地验证用户的身份和权限。这种无状态的特性是我个人觉得JWT最吸引人的地方，它极大地简化了分布式系统中的认证管理。
JWT的安全性如何保障？它有哪些常见的安全隐患？
谈到JWT，安全性是绕不开的话题。JWT的安全性主要通过其签名机制来保障。签名确保了令牌一旦被签发，其内容在传输过程中就不能被随意篡改。如果有人试图修改载荷中的信息（比如把普通用户改成管理员），那么签名校验就会失败，服务器会拒绝这个令牌。但需要明确的是，JWT本身并不加密载荷内容，它只是编码。这意味着任何获取到JWT的人都可以解码头部和载荷，看到里面的信息。因此，在我看来，敏感信息不应直接放在JWT的载荷中。
尽管有签名保护，JWT并非没有安全隐患。一个常见的风险是令牌泄露。如果JWT被攻击者获取，他们就可以冒充用户进行操作，直到令牌过期。这通常发生在跨站脚本攻击（XSS）中，恶意脚本窃取了存储在客户端的JWT。所以，将JWT存储在
localStorage时需要特别小心，并采取内容安全策略（CSP）等措施来缓解XSS风险。
另一个潜在问题是弱密钥或算法选择不当。如果服务器使用的密钥太弱，攻击者可能通过暴力破解来伪造签名。另外，历史上也出现过算法混淆攻击（algorithm confusion attack），即攻击者诱导服务器使用非对称算法的公钥来验证用对称算法私钥签名的令牌。虽然现代JWT库已经很好地解决了这个问题，但开发者仍需警惕。
为了增强JWT的安全性，有几点是至关重要的：始终使用HTTPS来传输JWT，防止中间人攻击窃取令牌。使用足够长且复杂的密钥。设置合理的令牌过期时间，即使令牌被盗，其有效时间也有限。对于长时间会话，可以结合使用短生命周期的访问令牌（Access Token）和长生命周期的刷新令牌（Refresh Token），将刷新令牌安全地存储在HttpOnly Cookie中，以降低XSS风险。服务器端也应该有能力在必要时使某个JWT失效（如用户登出、密码更改），尽管这会稍微违背JWT的无状态原则，但在某些场景下是必要的安全权衡。
JWT与传统Session认证方式有何不同？各自的优缺点是什么？
在讨论用户认证时，JWT常常被拿来与传统的Session（会话）认证方式进行比较。它们之间最根本的区别在于“状态”的管理。
传统的Session认证是“有状态”的。当用户登录成功后，服务器会创建一个会话，将用户的身份信息存储在服务器端的内存或数据库中，并生成一个唯一的Session ID，这个ID通常通过Cookie发送给客户端。客户端在后续请求中携带这个Session ID，服务器通过它来查找并验证对应的会话信息。这种方式的优点在于，服务器可以方便地管理用户的状态，比如强制用户下线，或者在会话期间存储一些临时数据。然而，它的缺点也很明显，尤其是在分布式系统或微服务架构中。为了保证所有服务器都能识别同一个Session ID，需要实现Session共享机制（如使用Redis等外部存储），这增加了系统的复杂性。而且，如果服务器宕机，存储在内存中的Session信息可能会丢失。
而JWT则是“无状态”的。一旦JWT被签发，所有必要的认证和授权信息都包含在令牌本身中，服务器不需要在自己的存储中维护会话状态。每次请求，服务器只需要验证JWT的签名和有效期即可。这种无状态的特性给系统带来了巨大的可伸缩性优势。任何一个服务器节点都可以独立地验证JWT，无需担心Session共享问题，这非常适合负载均衡、微服务架构以及移动应用和跨域认证场景。
当然，无状态也带来了挑战。最显著的一点是，服务器无法轻易地“撤销”一个已签发的JWT，除非等到它自然过期。这意味着如果一个JWT被盗，攻击者可以一直使用它直到过期。为了解决这个问题，通常会引入黑名单机制（blacklist），将需要失效的JWT加入一个服务器端列表，每次验证时都检查是否在黑名单中。但这又引入了一点“状态”，需要权衡。另外，JWT的载荷会随着每次请求发送，如果载荷信息过多，会增加请求的大小，影响网络性能。所以，在设计JWT时，应尽量只包含必要的、非敏感的信息。
如何在实际项目中有效使用JWT，避免常见陷阱？
在实际项目中有效使用JWT，需要一套深思熟虑的策略，以充分发挥其优势并规避潜在风险。我个人在实践中总结了一些关键点，希望能帮助大家。
首先，也是最重要的一点，是关于令牌的生命周期管理。我们通常会采用“访问令牌（Access Token）+ 刷新令牌（Refresh Token）”的组合。访问令牌的生命周期应该设置得非常短，比如几分钟到几小时。这样即使访问令牌被盗，其有效时间也有限。而刷新令牌则拥有较长的生命周期，用于在访问令牌过期后，向认证服务器请求新的访问令牌。刷新令牌的安全性至关重要，它应该被存储在
HttpOnly且
Secure的Cookie中，这样可以有效防止XSS攻击窃取。访问令牌则可以存储在客户端的内存中，或者
localStorage，但后者需要配合严格的CSP策略。
其次，关于令牌的撤销机制。尽管JWT是无状态的，但在用户登出、密码修改或检测到可疑活动时，我们仍然需要让某个JWT立即失效。这时，引入一个服务器端的“黑名单”或“撤销列表”是必要的。每当需要使某个JWT失效时，就将其标识符（如
jticlaim）加入到这个列表中。在每次验证JWT时，除了检查签名和过期时间，还需要额外查询这个列表。虽然这会引入一点点状态管理，但这无疑是在安全与便利之间做出的一个合理权衡。
再者，对JWT的验证要全面。除了签名和过期时间（
exp），还要验证其他重要的声明，比如“不早于（
nbf）”、“签发者（
iss）”和“受众（
aud）”等，以确保令牌的合法性和适用范围。同时，务必使用强壮的签名算法（如HS256或RS256）和足够复杂的密钥，并确保密钥的妥善保管，绝不能硬编码在客户端代码中。
最后，永远不要在JWT的载荷中放置敏感信息，因为载荷只是Base64Url编码，而非加密。任何能够获取到JWT的人都可以解码并查看其内容。对于真正的敏感数据，应该通过加密或者仅在服务器端存储并关联用户ID的方式来处理。而且，要留意JWT的整体大小，避免在载荷中塞入过多不必要的信息，这会增加每次请求的网络开销。
通过这些实践，我们可以在享受JWT带来的无状态、可伸缩性优势的同时，有效地管理其固有的安全风险，构建一个既高效又安全的认证授权系统。
