46 lines
2.0 KiB
Markdown
46 lines
2.0 KiB
Markdown
|
是的，Spring Security 在每次带有 token 的请求中，确实都会走一遍认证流程，但并不一定每次都“存储”认证信息，具体行为取决于你使用的 token 类型（如 JWT、Session、OAuth2 等）和安全配置。
|
|||
|
|
|
|||
|
|
一、JWT（常见于无状态登录）
|
|||
|
|
如果你使用的是 JWT（JSON Web Token）这种无状态认证机制：
|
|||
|
|
|
|||
|
|
每次请求都要带上 token（通常放在 Authorization Header 中）
|
|||
|
|
|
|||
|
|
Spring Security 会通过一个过滤器（如 OncePerRequestFilter）解析这个 token
|
|||
|
|
|
|||
|
|
验证 token 的有效性（比如签名、过期时间）
|
|||
|
|
|
|||
|
|
从 token 中解析用户信息（如用户名、角色），然后在当前请求的 SecurityContext 中构建认证对象
|
|||
|
|
|
|||
|
|
请求处理完后，SecurityContext 是线程局部的，不会跨请求存储，下次请求又要重新走这个流程
|
|||
|
|
|
|||
|
|
✅ 好处是服务无状态、扩展性强
|
|||
|
|
❌ 每次请求都要解析和验证 token，有一定性能开销
|
|||
|
|
|
|||
|
|
二、Session（默认方式）
|
|||
|
|
如果你使用的是 Spring Security 默认的基于 Session 的认证机制：
|
|||
|
|
|
|||
|
|
登录成功后服务端会生成一个 SessionId，并将其通过 Cookie 返回给客户端
|
|||
|
|
|
|||
|
|
客户端下次请求自动带上 Cookie
|
|||
|
|
|
|||
|
|
Spring Security 会通过这个 SessionId 直接从服务端 Session 中获取用户的认证信息
|
|||
|
|
|
|||
|
|
如果存在有效 Session，就不需要重新认证，不走身份验证流程
|
|||
|
|
|
|||
|
|
✅ 好处是性能较高
|
|||
|
|
❌ 缺点是服务有状态，不利于分布式部署（需共享 Session）
|
|||
|
|
|
|||
|
|
三、OAuth2 Token（Resource Server 模式）
|
|||
|
|
如果你用的是 OAuth2，比如使用 spring-security-oauth2-resource-server：
|
|||
|
|
|
|||
|
|
每次请求带上 Bearer Token
|
|||
|
|
|
|||
|
|
Spring Security 会通过配置好的 JwtDecoder 验证 token（或远程调用 introspection endpoint）
|
|||
|
|
|
|||
|
|
同样会在请求级别构建一次 Authentication 对象，不会存储
|
|||
|
|
|
|||
|
|
总结
|
|||
|
|
场景 每次验证 Token 认证信息是否持久化
|
|||
|
|
JWT ✅ 是 ❌ 否，线程局部
|
|||
|
|
Session ❌ 否，登录一次 ✅ 是，存储在 Session
|
|||
|
|
OAuth2 Resource Server ✅ 是 ❌ 否，线程局部
|