JWT认证需嵌入请求生命周期：验证分两层中间件，密钥用Firebase库安全解析；access_Token不入库，refresh_token须哈希存库并滚动刷新；多端登录靠jti+设备指纹实现粒度控制。
php 的 JWT 认证不是“加个库就能用”，关键在怎么把它嵌进请求生命周期里——特别是验证时机、密钥管理、token 刷新和状态解耦这四点没理清，后面会反复踩坑。
JWT 验证该放在 laravel 中间件还是自定义路由层？
必须放中间件，且要分两层：前置中间件（如 EnsureTokenExists）只检查 Authorization 请求头是否存在并提取 Bearer token；核心验证中间件（如 ValidateJwtToken）才做解析、签名校验、过期判断和 payload 合法性检查。跳过第一层会导致后续逻辑收到空 token 而抛出未捕获异常。
常见错误是把解析和数据库查用户写在同一中间件里——一旦 token 无效，却还去查 users 表，既浪费资源又暴露行为特征。
- 不要在中间件里调用
Auth::user()或User::find()，JWT 的用户信息应完全来自 payload - payload 中必须含
sub（用户 ID）、exp（unix 时间戳）、iat，建议加jti用于防重放 - Laravel 项目中，避免用
php-jwt原生库手动解析，优先用firebase/php-jwt的JWT::decode()并传入new FirebaseJWTKey($secret, 'HS256')
token 签发时要不要存数据库？refresh_token 怎么安全落地？
access_token 绝对不要入库，它本就是无状态凭证；但 refresh_token 必须落库，且字段设计要包含：token_hash（bcrypt 加盐哈希值，不存明文）、user_id、expires_at、revoked_at、user_agent 和 ip_address。
立即学习“PHP免费学习笔记（深入）”；
刷新流程不是“拿旧 refresh_token 换新 access_token”就完事——每次使用后必须立即失效旧 token，并生成新 refresh_token（即滚动刷新）。否则攻击者截获一个 refresh_token 就能无限续期。
- 签发 access_token 时，
exp建议设为 15–30 分钟；refresh_token 的exp可设为 7 天，但必须配合revoked_at字段实现主动吊销 - 不要用 PHP session 存 refresh_token，它破坏无状态原则；更不要塞进 cookie 且没设
HttpOnly+Secure - refresh 接口必须校验原
refresh_token的哈希值，且更新时用DB::transaction()包裹查询+插入+删除三步，防止并发重复使用
如何让同一个用户多端登录互不影响，又支持单端踢出？
靠 jti（JWT ID）+ 设备指纹组合实现。签发 token 时，将 jti 设为唯一 UUID，并存入数据库关联到 user_id 和设备标识（如 sha256(user_agent . ip . app_version)）。验证 access_token 时，先查 jti 是否在有效列表中；踢出某端，只需删对应记录。
别用 “用户下线即删所有 token” 这种粗暴方式——它会让用户在手机端操作时，意外登出正在用的桌面端。
- 数据库表名建议叫
jwt_active_tokens，字段含jti（主键）、user_id、fingerprint、created_at - access_token 的
exp时间很短，所以这个表数据可设 TTL 自动清理，或用定时任务每天删过期项 - 前端必须在每次请求 header 带上
User-Agent和自定义X-App-Version，后端拼接时顺序固定，否则同一设备算出不同 fingerprint
真正难的不是生成 token，而是让每个环节都默认信任 payload、拒绝回源查库、把状态控制粒度压到设备级——这些决策一旦定错，后期改起来要动接口、改前端存储逻辑、补审计日志，比从零写还累。