17370845950

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 \Firebase\JWT\Key($secret, 'HS256')

token 签发时要不要存数据库？refresh_token 怎么安全落地？

access_token 绝对不要入库，它本就是无状态凭证；但 refresh_token 必须落库，且字段设计要包含：token_hash（bcrypt 加盐哈希值，不存明文）、user_id、expires_at、revoked_at、user_agent 和 ip_address。

刷新流程不是“拿旧 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、拒绝回源查库、把状态控制粒度压到设备级——这些决策一旦定错，后期改起来要动接口、改前端存储逻辑、补审计日志，比从零写还累。