Jwt

背景知识 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（版权归原作者所有）。 ...

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 的判定逻辑完全对应： ...