在Web身份验证的上下文中了解JSON Web令牌(JWT)

在Web客户端 – 服务器身份验证的上下文中关于JWT的一些陈述:

> 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中的用户数据最好分别加密.

这个设计有什么缺陷?有什么可以改进的?

解决方法

你的帖子很大,如果我误解了什么就很抱歉

看来你正在谈论访问令牌和刷新令牌之类的东西.请参阅thisthis auth0文章. Google oauth2正在使用类似的东西:

>访问令牌:授权访问受保护资源.寿命有限.必须保密,由于寿命缩短,安全考虑不那么严格.
>刷新令牌:允许您的应用程序获取新的访问令牌,而无需重新进行身份验证.寿命长.存放在安全的长期存储中

在这个post中,您可以找到使用建议:

> Web应用程序:在令牌过期之前刷新令牌,每次用户打开应用程序和每个固定时间段(1小时?)
>移动/本机应用程序:应用程序登录一次.刷新令牌不会过期,可以交换有效的JWT.考虑更改密码等特殊事件

回答你的问题,我认为API0充当刷新令牌服务器,API1,2和3需要访问令牌.避免使用HTTPS的ManInTheMiddle,整体使用API​​0

相关文章

操作步骤 1、进入elasticsearch的plugin,进入ik。进入config。 2、在config下面建立以.dic为后缀的字典...
lengend data数据中若存在&#39;&#39;,则表示换行,用&#39;&#39;切割。
代码实现 option = { backgroundColor: &amp;#39;#080b30&amp;#39;, tooltip: { trigger: &...
问题原因 原因在于直接在js中取的变量并复制给var变量。 于是就变成这样。 解决办法 var data = &#...
前言 最近做了一个调查问卷导出的功能,需求是将维护的题目,答案,导出成word,参考了几种方案之后,选...
对于很多人来说,用字符编码都是熟能生巧,而不清楚为什么是那样的字符编码,所以我在这列了一个表,翻...