面试官：Session和JWT有什么区别？
2021-02-03 15:53:48
Session和JWT的核心区别在于工作原理、存储方式、有效期管理及适用场景，具体如下：
一、工作原理差异Session机制
服务器主导：用户首次登录时，服务器生成唯一Session ID并存储用户状态（如登录状态、权限等），通常将Session ID通过Cookie返回客户端。
状态化验证：后续请求中，客户端携带Session ID（如Cookie中的JSESSIONID），服务器通过查询存储的Session信息验证用户身份。
依赖会话存储：需维护Session存储（内存或数据库），分布式系统中需额外处理会话共享问题（如Redis集群）。
JWT机制
客户端主导：用户登录后，服务器生成包含用户信息、过期时间等数据的JWT（Header+Payload+Signature），直接返回给客户端。
无状态验证：客户端在请求头（如Authorization: Bearer <token>）中携带JWT，服务器仅需验证签名和过期时间，无需查询存储。
自包含性：JWT自身包含所有认证信息，减少对服务器资源的依赖。
Session存储
服务器端：Session数据通常保存在内存（单机）或数据库/缓存（分布式），需处理存储同步和扩展性问题。
客户端存储：仅存储Session ID（Cookie或URL参数），数据量小但需防范CSRF攻击。
JWT存储
客户端存储：JWT完整数据存储在客户端（LocalStorage、SessionStorage或Cookie），需防范XSS攻击（避免使用JavaScript直接读取敏感数据）。
服务器无状态：无需存储会话数据，天然支持分布式和微服务架构。
Session有效期
服务器控制：通过配置Session超时时间（如30分钟无操作失效）动态管理，可随时修改用户状态（如强制登出）。
灵活性限制：需依赖服务器存储，分布式系统中会话同步可能成为瓶颈。
JWT有效期
令牌内嵌：通过Payload中的exp（过期时间）字段设置，生成后不可篡改，客户端需自行处理过期逻辑（如跳转登录页）。
灵活性优势：
支持自定义字段（如用户角色、权限列表），减少服务器查询。
适用于无状态场景（如微服务间认证），但需额外机制处理令牌撤销（如黑名单）。
Session适用场景
需要动态修改用户状态的场景（如管理员临时提升权限）。
对安全性要求极高且可接受服务器存储开销的系统（如银行后台）。
传统单体架构或会话同步成本可控的分布式系统。
JWT适用场景
分布式系统或微服务架构（如Spring Cloud），需无状态认证。
跨域场景（如前后端分离项目），JWT可轻松通过HTTP头传递。
对性能要求高、需减少服务器存储开销的系统（如移动端API）。
Session安全性
需防范Session固定攻击（固定Session ID劫持）和CSRF攻击（需配合CSRF Token）。
分布式系统中需确保Session存储的高可用性和一致性。
JWT安全性
需防范XSS攻击（避免JWT存储在易被JavaScript读取的位置）和令牌泄露（使用HTTPS传输）。
签名算法需足够安全（如HS256、RS256），避免使用弱密钥。
扩展性优势：支持添加自定义声明（如设备信息、IP限制），灵活适应业务需求。
- 选择Session：若系统需动态管理用户状态、可接受服务器存储开销，或处于传统架构环境。
- 选择JWT：若系统为分布式/微服务架构、需跨域支持、追求无状态扩展性，或对性能要求较高。
- 混合方案：部分场景可结合两者（如用JWT认证，Session存储敏感操作日志），平衡安全性与灵活性。
热门标签
