面试题答案
一键面试JWT工作原理
- 生成令牌：用户在前端输入登录信息，发送到后端。后端验证用户信息无误后，将用户相关数据（如用户ID、用户名等）作为载荷（Payload），再加上头部（Header，包含令牌类型和签名算法等信息），然后使用密钥（Secret）按照指定签名算法（如HMAC SHA256）生成签名（Signature），将Header、Payload和Signature组合，以点号（.）分隔，最终形成JWT。
- 传递令牌：后端将生成的JWT返回给前端。前端通常将其存储在本地（如localStorage、sessionStorage或cookie）。之后前端每次向后端发起请求时，会在请求头的Authorization字段中带上JWT，格式如
Bearer <token>。 - 验证令牌：后端接收到请求及JWT后，从请求头中提取JWT，根据JWT中的Header部分知晓签名算法，使用相同的密钥和算法重新计算签名，并与JWT中的签名进行比对。若比对一致且令牌未过期，说明令牌有效，后端可以从Payload中获取用户相关信息进行后续操作。
安全性优势
- 无状态：传统session - cookie认证方式下，服务器需要在内存中维护用户的session状态，而JWT是无状态的，服务器无需存储用户会话信息。这使得服务器更容易进行水平扩展，同时减少了服务器因存储大量session数据带来的安全风险，如session劫持、session泄漏等。因为攻击者即使获取了session数据，在无状态的JWT机制下也难以利用，因为服务器不依赖这些session数据来验证用户。
- 防止CSRF攻击：传统的cookie - based认证容易受到跨站请求伪造（CSRF）攻击，因为浏览器会自动在同源请求中带上cookie。而JWT通常不会存储在cookie中，而是存储在localStorage或sessionStorage等地方，并且在发送请求时通过自定义请求头传递，这样就不会被浏览器自动携带，从而降低了CSRF攻击的风险。
- 签名验证：JWT使用签名来验证令牌的完整性和真实性。只有拥有正确密钥的服务器才能生成有效的签名并验证令牌。如果攻击者篡改了JWT的内容，签名验证就会失败，后端可以立即识别并拒绝请求。相比之下，传统session - cookie认证方式没有这种对数据完整性的强验证机制，攻击者可能篡改cookie中的数据而不被轻易发现。
- 分布式环境友好：在分布式系统中，传统的session认证方式需要在多个服务器之间共享session数据，这增加了复杂性和安全风险，如数据同步问题和共享存储的安全隐患。而JWT可以在任何知晓密钥的服务器上进行验证，无需在服务器间共享状态，这使得它在分布式和微服务架构中更具安全性和灵活性。