基于令牌的身份验证的替代方法答案

【问题标题】：Alternate approaches to token based authentication基于令牌的身份验证的替代方法
【发布时间】：2023-03-29 02:53:02
【问题描述】：

我有一个 RESTful API，用户将通过一组网络/移动客户端访问它，我正在尝试弄清楚如何处理令牌身份验证。我的理解是传统令牌认证的工作原理如下：

通过提供用户/通行证的用户身份验证，接收回令牌和过期
直到，每个请求都传递令牌
到期后，请求新令牌（通过提供单独的“刷新”令牌或仅通过用户/密码重新进行身份验证）

是否有充分的理由不为每个请求生成新令牌？即：通过用户/通行证请求初始令牌。此令牌与第一个 API 请求一起传递，该请求返回 api 响应的内容以及必须与以下请求一起传递的新令牌......这种方法的优点是用户接受的每个请求（操作）'重置令牌身份验证的到期时间，以便令牌到期时间基本上成为用户可以在不注销的情况下处于非活动状态的时间段。有充分的理由不使用这种方法吗？上面列出的方法似乎更普遍（这就是我问的原因）。

最后，一个稍微相关的问题。是什么阻止了正在监视网络的人从用户那里获取令牌？特别是在第一种方案中，似乎很容易做到（在第二种方法中，您需要捕获传入的请求，然后在用户之前快速获取下一个令牌）。

【问题讨论】：

标签： authentication token restful-authentication

【解决方案1】：

根据我的阅读，您需要一个滑动窗口，在该窗口中对用户进行身份验证。到期窗口内的每个新请求都会延长会话。如果我理解正确，我会建议另一种方法；每次成功验证请求时，更新您拥有令牌的商店并更新到期时间。这样，您就不必每次都为获取新令牌而烦恼您的用户。所以，是的，有一个很好的理由不这样做：你的用例没有必要这样做，只会惹恼用户。

通过上述方法，我假设您有一个商店（数据库），您可以在其中保存您的令牌 + 到期日期。

所以流程是这样的：

用户提供用户名+密码
在商店中创建记录
给用户令牌
每次请求成功时更新存储

在相关说明上；不要给用户到期日期。例如，在使用 cookie 时这很好，但这只是作为一种额外的安全措施有用。

关于你稍微相关的问题；如果您不使用 TLS/SSL/HTTPS，没有什么能阻止任何人获取令牌。始终使用 TLS（即 SSL，或多或少是 HTTPS）。

【讨论】：

我正在使用带有危险 TimedJSONWebSignatureSerializer（JSON Web 签名实现）的 python。所以不，我不认为我正在使用数据库来存储令牌。并且由于过期是令牌的一部分，因此您无法扩展它（您将获得一个新令牌）。澄清一下：API 的“用户”是我自己（最终用户不打算直接使用 API，只使用其中一个客户端应用程序）。所以我最关心的是这种方法的安全隐患。
另外 - '标准'模型中过期的原因是客户端可以知道何时请求新令牌而不必命中资源，由于身份验证失败而被拒绝（令牌过期)，然后请求新的令牌。那有意义吗？显然，对于滑动身份验证窗口，这不是必需的（这也是为什么它看起来是个好主意的部分原因！）
将过期时间发送给客户端确实可以传达有关何时请求新令牌的信息。但绝不应该以客户可以更改的方式使用它。对于无法完成的 JWT，这确实是一种替代方法。由于您是 API 的唯一用户，因此如何处理过期令牌当然取决于您。无论如何，您都需要做点什么。但是定期请求新令牌会更容易吗？保持一切美好和分离。