JWT 的过期和刷新机制是否有脱裤子放屁的嫌疑（安全嫌疑）
jwt-auth 有两个重要的参数，可以在 .env 中进行设置
JWT_TTL生成的 token 在多少分钟后过期，默认 60 分钟JWT_REFRESH_TTL生成的 token，在多少分钟内，可以刷新获取一个新 token，默认 20160 分钟，14 天。
JWT_REFRESH_TTL即然是14天，也就是JWT_TTL设置为60分钟也没任何意义啊，只要TOKEN泄漏了，他一样可以不断请求刷新接口来获得新的TOKEN
那这个JWT_TTL就没意义了
另外，那个官方自带的Sanctum API我感觉也不安全，TOKEN一颁发有效时间就非常久，虽然可以设置有效时间，但是有效时间不能像SESSION那样自动延长，而是会被回收的时候突然间回收，操作一半就掉线了
关于 LearnKu
粤公网安备 44030502004330号
是这样的。不过，大多的用的就是你说的这种。其实，该是需要区分成accesstoken和刷新token的，刷新token只做刷新获取权限token就行了，不要合在一起。也可以认为你说的这种是有漏洞的
那你怎么把用户踢下线？比如勾选14天内登录有效。
脱裤子放屁。。。然后黑名单存redis
这种方式是不标准的，本身就有漏洞
用 jwt 就不要考虑什么安全性了，服务器不换 secret 是没办法销毁已经发放的 token 的。
你可以用redis自己搞一套，因为jwt那个包有很多问题
像jwt这种类似的认证包，有什么推荐的么，我使用 sanctum 的时候也有这种感觉。
创建的 token 前面有个数字，很诡异的感觉。 类似于这种
1|xxxxxxxx看来不止我一个人怀疑这个方式不安全，看来核心的业务不能用前后端分离，比如后台
自动延长可以用程序实现，比如发token时记录一个时间，然后存redis，然后，登录时对比，可以写代码提醒前端调接口更换
我一直感觉就是脱裤放屁，心里安慰，这是给爬虫的找事