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 ✅ 是 ❌ 否，线程局部 |