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

Posted 2023-03-10

【中文标题】了解 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部分（只有一个

我会把我的问题改写得更短