Authentication

背景知识 github.com/golang-jwt/jwt Authentication 和 Authorization 的区别 Authentication: 认证，指的是验证用户的身份，例如你希望以 A 的身份登录，那么应用程序需要通过用户名和密码确认你真的是 A 。 Authorization: 授权，指的是确认你的身份之后提供给你权限，例如用户 A 可以修改数据，而用户 B 只能阅读数据。 由于 http 协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。因此我们希望用户登录成功之后的每一次 HTTP 请求，都能够保存他的登录状态。 目前主流的用户认证方法有基于 token 和基于 session 两种方式，常见的还有三种细分形态： 无状态 JWT (Stateless JWT)：包含 Session 数据的 JWT Token，Session 数据直接编码进 Token 内。 有状态 JWT (Stateful JWT)：包含 Session 引用或其 ID 的 JWT Token，Session 数据存储在服务端。 Session token（又称 Session cookie）：标准的、可被签名的 Session ID，例如各类 Web 框架 (译者注: 包括 Laravel) 内已经使用了很久的 Session 机制，Session 数据同样存储在服务端。 以上背景知识整理自 Wi1dcard 的文章，原文地址：https://learnku.com/articles/22616（版权归原作者所有，商业转载请联系作者获得授权）。 Session vs JWT 详解 以下内容整理自 chengkai 的文章《聊一聊JWT与session》，原文地址：https://juejin.cn/post/6844903542449242126（版权归原作者所有）。 ...

登录之外，很多系统还需要"关闭浏览器后仍保持登录"，这就是 remember-me（记住我）。Spring Security 提供两种实现，机制和安全性差别很大。SecurityFilterChain 整体认证流程见 Spring Security。 常见误解：不是"让 session 活得更久" 容易望文生义地以为 remember-me 就是把普通 session 的过期时间设得很长，下次访问时顺便刷新一下 session id。实际上标准做法是两套凭证分层： 登录后先发一个短期 session（比如 30 分钟）。 勾选了 remember-me，再额外发一个长期凭证（cookie 里的 series:token）。 下次访问时如果短期 session 已失效，服务端用长期凭证验证通过后，重新建立一个新的 session，而不是延长旧 session 的寿命。 这样做的原因：短期 session 追求高频、低延迟访问（常放内存/Redis），长期凭证追求低频、可撤销、可审计（放数据库即可）。如果把两者合并成"一个超长有效期的 session"，会导致服务端要长期保留大量会话状态，且缺乏按设备单独撤销的能力（下文详述）。 简单哈希令牌（TokenBasedRememberMeServices，默认方式） Cookie 内容： username:expirationTime:md5(username + ":" + expirationTime + ":" + password + ":" + key) 优点：无状态，不查数据库。 缺陷：服务端无法单独让某一台设备的 cookie 失效——除非改密码或改全局 key，那样会让所有设备同时下线；且签名依赖密码本身，密码不变、cookie 一旦泄露就能一直重放。 持久化令牌（PersistentTokenRepository） 数据库维护一张 persistent_logins 表，每一行代表一次登录（一个设备/浏览器）： series username token last_used Cookie 里存的是 series:token（两个随机值），不含密码信息。 每次带着 remember-me cookie 的请求认证成功后，token 值会轮换，但 series 不变。判定逻辑发生在服务端：先用 series 查到数据库里当前记录的 token 值，再和客户端发来的 token 比对——相等则正常轮换；series 能查到但 token 不相等，说明这个值是已经被换掉的旧值又出现了一次，PersistentTokenBasedRememberMeServices 会判定为 cookie 窃取（cookie theft），删除该 series 的记录并强制重新登录。 因为每个设备对应独立的 series 行，服务端可以按行删除来单独踢掉一个设备，不影响其他设备的登录状态。这就是"跨设备失效控制"：本质是把认证状态从"无状态签名"换成了"以设备为粒度的数据库记录"。 需要澄清一点：series 并不是浏览器指纹或设备硬件 id，它只是"这一次 remember-me 登录时生成、存在这台设备 cookie 里的随机值"。它不校验设备身份，如果 cookie 原样被复制到另一台机器，series 照样验证通过——真正防重放靠的是上面的轮换 + 比对机制，不是设备识别。另外这个 cookie 和普通 cookie 一样，只要没限制 path，每次请求都会被发送，传输频率跟 session cookie 无异；真正低频的是服务端"校验/轮换"这个动作的触发频率（只在 session 失效时才用得上）。 跨设备失效控制的三个能力 可枚举：按 username 查询 persistent_logins 表，能看到该用户当前所有"记住我"的设备。 可单点撤销：删除某一行 series，对应设备下次请求 token 校验失败，强制走正常登录。 可全量撤销：改密码时清空该用户所有 series 记录，实现"改密码后所有设备强制下线"。 与 JWT refresh token 的对照 OAuth2 / JWT 体系里常见的 refresh token，跟这里的长期凭证是同一类角色：都是"低频使用、用来重建短期凭证"的东西。但安全性取决于实现方式： ...

OAuth2 / JWT 体系里的 refresh token，如果只靠"签名 + 过期时间"校验，是无状态的：服务端不记录任何已发放、已使用的记录，因此没法检测重放、也没法单独撤销某一次登录。要补齐这块安全能力，业界通用做法叫 refresh token rotation（轮换）+ reuse detection（重放检测），思路和 Spring Security 的持久化 remember-me（见 Spring Security Remember Me 实现机制）几乎一致，只是术语不同。 无状态 refresh token 的问题 最简单的实现：refresh token 就是一个长期有效的签名字符串，服务端只验证签名和过期时间，不查库。 优点：无状态，扩展性好。 缺陷：refresh token 一旦泄露，在过期之前可以被无限次使用，服务端发现不了，也撤销不了单独一次登录（除非撤销全部密钥或拉黑名单）。 这跟 Spring Security 默认的 TokenBasedRememberMeServices（哈希令牌）是同一类问题：都是"无状态签名"，天然缺少重放检测和单点撤销能力。 Rotation + Reuse Detection 的做法 给每一条 refresh token 的"血统"维护一个 family_id（有的实现里叫 session_id、lineage_id，作用等价于 remember-me 里的 series）： family_id current_token issued_at used 用户登录时，颁发 family_id + 第一个 refresh_token，同时记录到数据库。 客户端用 refresh_token 换新的 access_token 时，服务端同时颁发一个新的 refresh_token，旧值作废，数据库里 current_token 更新为新值。 如果收到的 refresh_token 匹配 family_id 但不等于数据库里记录的 current_token——说明这个 token 已经被换过一次了，现在又被用了一次，只有两种可能：客户端重复提交，或者 token 被别人窃取后重放。 一旦判定为重放，直接撤销整条 family_id，强制该登录下线重新认证。 这跟持久化 remember-me 的判定逻辑完全对应： ...

SecurityFilterChain SecurityFilterChain 是 Spring Security 的核心抽象，代表一条作用于 HTTP 请求的安全过滤器链。每个进入应用的请求都会依次经过链中的若干 Filter，完成认证（Authentication）、授权（Authorization）、CSRF 防护、会话管理等工作。 底层机制：从 Servlet Filter 到 Spring Security Servlet 规范本身有 Filter 接口和 FilterChain 接口。Spring Security 通过以下两层代理接入这套机制： DelegatingFilterProxy：在 Servlet 容器（Tomcat）层面注册的 Filter，作用是把请求桥接到 Spring 容器中的 Bean。它本身不做安全逻辑，只是一个"入口代理"。 FilterChainProxy：Spring 容器中的真正实现，也是一个特殊的 Filter。它持有所有注册的 SecurityFilterChain Bean，收到请求后，按顺序匹配第一条能处理该 URL 的链，然后依次执行链中的每个 Filter。 HTTP 请求 → Tomcat FilterChain → DelegatingFilterProxy（Servlet Filter，桥接到 Spring，Bean 名固定为 springSecurityFilterChain） → FilterChainProxy（Spring Bean，收集所有 SecurityFilterChain） → SecurityFilterChain 1（匹配 /api/**） UsernamePasswordAuthenticationFilter BearerTokenAuthenticationFilter ExceptionTranslationFilter AuthorizationFilter ... → SecurityFilterChain 2（匹配 /**） ... ← 链中最后一个 Filter 放行（chain.doFilter()），控制权交回 DelegatingFilterProxy → Tomcat FilterChain 继续执行其余 Filter（如果有） → DispatcherServlet → HandlerMapping 找到目标 Controller 方法 → Controller SecurityFilterChain Bean 如何被收集并接入请求 在 @Configuration 类里写的 @Bean public SecurityFilterChain filterChain(...) 方法，只是往 IoC 容器里注册了一个数据对象——具体实现类是 DefaultSecurityFilterChain，内部就是一个 Filter 列表加一个 RequestMatcher。真正让这份数据接入请求处理流程，还需要另外两步： ...