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

Posted

技术标签:

【中文标题】了解 Web 身份验证上下文中的 JSON Web 令牌 (JWT)【英文标题】:Understanding JSON Web Token (JWT) in context of web authentication 【发布时间】:2016-12-10 12:55:17 【问题描述】:

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

    JWT 对于中间人攻击并不安全。在安全方面从客户端向服务器发送 JWT 等同于发送散列密码。 JWT 可以携带用户详细信息作为有效负载。在不访问数据库中的实际数据的情况下使用这些数据被称为 JWT 功能之一。但是,如果数据库数据发生更改,此 JWT 数据不会失效/更新。 从 2 开始。在某些情况下,应根据 DB 验证 JWT 有效负载和/或应明智地设置时间戳以在一段时间后使 JWT 失效。

客户必须多次调用 API 才能完成一个工作流的真实示例:用户想知道从 A 到 B 的最短路线的价格。我们使用两种类型的 JWT 一种“authJWT” & 一个“普通的 JWT”。

IF 客户端有一个 authJWT:客户端使用 authJWT 请求 API0(auth API)。 API0 根据数据库和时间戳检查 authJWT 签名和用户数据有效负载 ELSE:客户端使用密码请求 API0(身份验证 API)并使用时间戳登录 JWT。 API0 检查密码和登录数据库并返回 authJWT 和“正常”JWT。 在这两种情况下:所有后续 API 都将使用“正常”JWT 调用,并且仅通过签名和时间戳验证有效性,但针对用户数据库。 客户端两次请求 API1 以获得地点 A 和地点 B 的搜索字符串的最佳匹配。服务器检查 JWT 签名和时间戳 客户端请求 API2 获取从地点 A 到地点 B 的最短路径。服务器检查 JWT 签名和时间戳 客户端请求 API3 获取短路路线的价格。服务器检查 JWT 签名和时间戳

这意味着中间人必须捕获对 API0 的调用才能获得真正的访问权限。捕获“正常” JWT 几乎没有效果,因为它会在 10 秒后过期。可能对 API 1-3 的调用甚至可以通过没有 SSL 加密的纯 HTTP 进行 - 但这当然取决于您的用例。在所有情况下,JWT 中的用户数据最好单独加密。

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

【问题讨论】:

【参考方案1】:

您的帖子很大,如果我误解了什么,请见谅

您似乎在谈论访问令牌刷新令牌之类的东西。请参阅 this 和 this auth0 文章。 Google oauth2 正在使用类似的东西:

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

在这个post 你可以找到使用建议:

Web 应用程序:在令牌过期前刷新令牌,每次用户打开应用程序和每个固定时间段(1 小时?)

移动/原生应用程序:应用程序登录一次。刷新令牌不会过期,可以换成有效的 JWT。考虑更改密码等特殊事件

回答您的问题,我认为 API0 充当刷新令牌服务器,而 API1、2 和 3 需要访问令牌。使用 HTTPS 避免 ManInTheMiddle,整体使用 API0

【讨论】:

我不知道node.js 足以推荐一个图书馆。在 jwt.io 中,您有所有语言的库链接。检查node.js部分(只有一个 我会把我的问题改写得更短

以上是关于了解 Web 身份验证上下文中的 JSON Web 令牌 (JWT)的主要内容,如果未能解决你的问题,请参考以下文章

Django Rest Framework(DRF) Json Web Token(JWT) 身份验证和登录过程

如何使用 Web API 来对 MVC 应用程序进行身份验证

需要帮助了解 ASP .Net MVC 用户身份验证/授权

通过不同域上的 REST Web 服务进行用户身份验证 - asp.net

用于用户身份验证的个人访问令牌和 json Web 令牌有啥区别?

向经典 ASP.NET Web 窗体应用和 Web API 应用添加共享身份验证