JWT 和 Session 做权限校验机制详解（面试高频）

在 Web 系统中，权限校验通常围绕“用户是谁、能做什么”展开。主流方案有两种：Session 认证与 JWT 认证。二者本质不同，但目标一致：完成身份认证与权限控制。

一、Session 认证机制（有状态方案）

1.1 基本工作流程

Session 模式的核心特点是：服务端保存登录状态

典型流程如下：

用户提交账号密码登录
服务端验证成功
服务端生成 Session，并存储用户信息
返回 sessionId 给客户端（通常通过 Cookie）
后续请求携带 sessionId
服务端根据 sessionId 查询 Session 获取用户信息

1.2 请求校验流程

每一次请求的验证过程如下：

1	request → sessionId → 服务端 → Session存储（Redis/内存）→ 用户信息 → 权限判断

1.3 权限校验方式

通常在服务端解析 Session 后：

获取 userId
查询角色 role
判断权限 permission
决定是否放行请求

1.4 Session 存储方式

常见实现：

单机：内存存储
分布式：Redis 存储（主流方案）

1.5 优缺点分析

优点

状态在服务端，更安全
可以主动失效（删除 Session 即登出）
便于权限即时更新
适合后台管理系统

缺点

服务端需要存储状态
分布式系统需要 Session 共享
扩展性较差
依赖 Redis 或一致性存储

二、JWT 认证机制（无状态方案）

2.1 基本工作流程

JWT（JSON Web Token）采用无状态认证机制：

用户登录成功
服务端生成 JWT（包含用户信息 + 签名）
返回 token 给客户端
客户端存储 token（localStorage / Cookie）
每次请求携带 JWT
服务端只做验签 + 解析，不保存状态

2.2 请求校验流程

1	request → JWT → 验签 → 解码 claims → 获取用户信息 → 权限判断

2.3 JWT 结构

JWT 由三部分组成：

1	header.payload.signature

各部分作用：

Header：算法类型（如 HS256）
Payload：用户信息（userId、role 等）
Signature：防篡改签名

2.4 权限校验方式

服务端流程：

验证签名是否正确
解析 payload
获取用户角色信息
判断权限是否允许访问接口

2.5 优缺点分析

优点

无状态，扩展性强
不依赖 Redis 存储
适合微服务架构
支持跨域、多端登录

缺点

无法主动失效 token
token 泄露风险较高
payload 只是编码，不是加密
权限变更不即时生效

三、Session vs JWT 对比总结

对比维度	Session	JWT
状态	有状态	无状态
数据存储	服务端	客户端
扩展性	较差	很强
性能开销	每次查存储	只验签
登出控制	可立即失效	需额外机制
分布式支持	依赖 Redis	天然支持
安全性	较高	中等

四、权限校验的本质（面试关键点）

无论使用 Session 还是 JWT，本质流程都是：

认证身份 → 获取用户角色 → 执行权限判断

常见权限模型：

RBAC（Role-Based Access Control）

1	用户 → 角色 → 权限

五、工程实践中的选择建议

使用 Session 的场景

单体应用
后台管理系统
强安全要求系统（如金融内部系统）
需要强制下线能力

使用 JWT 的场景

前后端分离架构
微服务系统
多端系统（Web + App + 小程序）
API Gateway 架构

六、面试高频总结

Session 是服务端保存状态，通过 sessionId 识别用户；
JWT 是客户端携带 token，服务端通过验签解析用户信息。

JWT和Session权限校验机制