ThinkPHP怎么实现JWT认证_ThinkPHP无状态登录验证方法【操作】

JWT认证需自建中间件解析Bearer Token，用firebase/php-jwt校验exp/iss/aud等claim，白名单放行登录等接口，refresh token应存Redis并绑定指纹，避免硬编码密钥。

JWT 认证在 ThinkPHP 8 中怎么配 middleware

简单来说，ThinkPHP 8 本身并没有把 JWT 当成默认组件打包进去。这意味着你绕不开一步——自己写一个中间件，用来拦截请求、解析 Authorization 头，并验证 token 是否有效。尤其要注意的是，别指望 think-auth 这类旧版本插件还能直接搬来用，它们大多是为 session 设计的，与 JWT 天生的无状态逻辑完全不兼容。

说干就干，具体操作可以这样走：

• 新建一个中间件类，比如 app/middleware/JwtAuth.php。在它的 handle() 方法中，用 $request->header('authorization') 来获取 token。通常客户端会采用 Bearer xxx 格式，记得要把前缀去掉，只留下 token 本体。
• 引入 firebase/php-jwt 库。先通过 composer require firebase/php-jwt 安装，接着调用 JWT::decode($token, $key, ['HS256']) 进行解析。需要留个心眼的是，解码过程中极有可能弹出各种异常，比如 DomainException 或 SignatureInvalidException。如果不做捕获处理，直接返回 401，用户体验会很糟糕。
• 验证通过之后，可以把解析出的用户 ID 挂在请求对象上：$request->withAttr('uid', $payload->uid)。这样后续的控制器就可以用 $this->request->attr('uid') 拿到当前用户，而不必非要把数据塞到 session 或全局变量里。
• 还有一点容易被忽视：不要在中间件里就去查数据库，加载用户的全部信息。JWT 的 payload 本身应该已经包含了必要字段（比如 uid、role）。真正的数据查询，还是留到业务层按需处理比较好。

Token 签发时哪些 claim 必须设、哪些容易漏

很多新手在签发 token 时常犯的错是：只往 payload 里塞了个 uid 就以为万事大吉。但一旦漏掉关键的 claim，要么校验失败，要么直接捅出安全窟窿。比如说，不设 exp 意味着 token 终身有效，不设 iss 或 aud，别的系统就能检起这个 token 随便用。

以下几点值得重点记下：

• 必设项：iat（签发时间）、exp（过期时间，比如 time() + 3600）、以及业务层面的 uid。这里多说一句，uid 最好不要用数据库的自增主键直接暴露给前端。
• 建议设项：iss 填你的 API 域名，比如 https://api.example.com；aud 则标明客户端身份，例如 web-app。在解码时，你可以把这两个字段传给 JWT::decode() 的第三个参数做进一步校验。
• 敏感字段方面，密码、手机号甚至邮箱，绝对不能放进 payload。JWT 本质只是 Base64 编码，不是加密，前端很轻松就能把内容解出来。
• 密钥的存放也是个大问题，千万别在代码里硬编码。最好把它写在 config/app.php 或环境变量里，然后用 Env::get('JWT_SECRET') 来读取，这样运维和不同环境切换都会灵活很多。

ThinkPHP 路由分组怎么跳过 JWT 验证

登录接口、注册接口、健康检查这些敏感点，必须提前放行，否则中间件一挂上去，所有请求直接 401 了。ThinkPHP 的路由分组中间件绑定机制有时会让人产生错觉，以为“分组下所有路由都走同一个中间件”。实际上，可以做到精确排除。

具体操作建议：

• 在 route/app.php 文件里，可以用闭包显式定义不需要鉴权的路由组。例如：
  Route::group(['middleware' => []], function () { Route::post('login', 'LoginController@login'); });
• 更推荐的做法是在 JWT 中间件内部做白名单判断。比如：
  if (in_array($request->url(), ['/api/login', '/api/register'])) { return $next($request); }。这种方式比分散在路由里写更方便统一控制。
• 注意不要试图用类似 Lara vel 的 except() 特性来过滤——ThinkPHP 8 的中间件并不原生支持这个参数，硬套的话很容易失效。
• 测试时，记得用 curl -H "Authorization: Bearer invalid-token" http://localhost/api/user 来验证拦截是否真的生效，别只盯着成功路径看。

为什么 Token 刷新总失败？关键在 refresh token 的存储和校验逻辑

JWT 本身是不可撤销、也不能直接刷新的。所谓的“刷新”，其实是服务端签发新 token 并作废旧 token 的组合动作。很多开发者卡在“我怎么知道哪个 token 已经被换过”这个问题上，结果刷新接口形同虚设。

实操建议：

• Refresh token 不应该塞进 JWT payload 里。它需要长期保持有效、并且能单独吊销。最稳妥的方案是把它存到 Redis 中，key 设置为 refresh:{uid}:{fingerprint}，value 存放对应的 access token 的 jti 及其过期时间。
• 签发新的 access token 时，务必生成新的 jti，并把它写在 JWT::encode() 的 jti 字段里。同时，将 Redis 中旧的 refresh:xxx 记录删除。
• Access token 校验时，如果发现它的 jti 已经在 Redis 的黑名单（比如一个 set 集合）中，直接拒绝放行——不要等它自然过期。
• 还有一个常被忽略的细节：别把 refresh token 放在 Cookie 里让浏览器自动携带。跨域场景下很容易被拦截，最好用 Authorization: Bearer xxx 的形式手动传，与 access token 的行为保持一致。

其实最容易被忽视的是 fingerprint 绑定。如果不记录设备指纹或 UA/IP 信息，攻击者只要拿到 refresh token，就能无限续期。哪怕只是存一个简单的 hash 值，也比完全不绑要安全得多。