> JWT在中间攻击中对人不安全.从客户端到服务器安全性发送JWT等于发送散列密码.
> JWT可以将用户详细信息作为有效负载.在不访问DB中的实际数据的情况下使用该数据被引用为JWT的一个特征.但是,如果DB数据发生更改,此JWT数据将不会失效/更新.
>从2开始,在某些情况下JWT有效负载应该针对DB进行验证和/或应该明智地设置时间戳以在一段时间后使JWT无效.
一个真实世界的例子,客户端必须多次调用API才能完成一个工作流程：用户想要知道从A到B的最短路径的价格.我们使用两种类型的JWT,即“authJWT”&一个“正常的JWT”.
> IF客户端有authJWT：客户端使用authJWT请求API0(auth API). API0检查authJWT签名&用户数据有效负载与DB&时间戳< 2天.返回新的“正常”JWT.
ELSE：客户端请求API0(auth API),密码为&使用时间戳登录JWT. API0检查密码&登录DB并返回authJWT& “正常”JWT.
在这两种情况下：将使用“普通”JWT调用所有后续API,并仅通过签名和时间戳验证有效性,但不会针对用户DB验证有效性.
>客户端请求API1两次以获得地点A和地点B的搜索字符串的最佳匹配.服务器检查JWT签名&时间戳< 10s并在需要时使用JWT用户数据.
>客户请求API2从A地到B处获得最短路径.服务器检查JWT签名&时间戳< 10s并在需要时使用JWT用户数据.
>客户要求API3获取卖空路线的价格.服务器检查JWT签名&时间戳< 10s并在需要时使用JWT用户数据.
这意味着中间的人必须接受对API0的调用才能获得真正的访问权限.捕获“正常”JWT几乎没有效果,因为它在10秒后到期.可能调用API 1-3甚至可以在没有SSL加密的情况下通过普通HTTP – 但这当然取决于您的用例.在所有情况下,JWT中的用户数据最好分别加密.
这个设计有什么缺陷？有什么可以改进的？
解决方法
看来你正在谈论访问令牌和刷新令牌之类的东西.请参阅this和this auth0文章. Google oauth2正在使用类似的东西：
>访问令牌：授权访问受保护资源.寿命有限.必须保密,由于寿命缩短,安全考虑不那么严格.
>刷新令牌：允许您的应用程序获取新的访问令牌,而无需重新进行身份验证.寿命长.存放在安全的长期存储中
在这个post中,您可以找到使用建议：
> Web应用程序：在令牌过期之前刷新令牌,每次用户打开应用程序和每个固定时间段(1小时？)
>移动/本机应用程序：应用程序登录一次.刷新令牌不会过期,可以交换有效的JWT.考虑更改密码等特殊事件
回答你的问题,我认为API0充当刷新令牌服务器,API1,2和3需要访问令牌.避免使用HTTPS的ManInTheMiddle,整体使用API0