访问令牌 刷新令牌正确的方法？

Question

我正在尝试使用 NodeJS 构建 RESTful API，但在 api 调用期间无法理解使用令牌对用户进行身份验证的正确方法。在阅读了一些博客和文章后，我想出了这些方法：

Access Token（AT）是包含唯一userId作为JWT有效负载的JWT令牌。1天后到期。
刷新令牌（RT）是使用uuid npm包的随机uuid。与用户文档一起存储在数据库中。
过程：

1. 当用户登录/注册服务器发布新AT RT时。
2. 如果AT过期，则用户向AT RT发送请求/刷新令牌路由。服务器通过将数据库中存储的RT与用户给定的RT进行匹配来检查RT的正确性，如果AT是有效的JWT令牌，则解码AT中存在的userId。若一切顺利，RT是正确的，AT是有效的JWT令牌，服务器将发布一个新的AT并将其发送给用户

在上述方法中，刷新令牌不会过期，所以如果RT来自恶意客户端，那么他可以发布n个访问令牌并使用它们调用api，直到用户再次登录，服务器生成新的AT RT对。因此，攻击者手中的RT没有用。

基于在刷新令牌上读取的 AuthO 文档的请求令牌轮换
访问令牌 （AT） 是包含唯一 userId 作为 JWT 有效负载的 JWT 令牌。1 天后过期。
Referresh Token（RT）是JWT代币。4-5个月后到期。作为刷新令牌数组存储在数据库中，而不是用户文档。
过程：

< li >当用户登录/注册服务器发出一对新的AT RT并将RT推入存储在数据库中的刷新令牌数组时。 < li >当AT过期时，用户使用旧的AT RT对请求/请求令牌路由，服务器生成新的AT RT对，同时存储

上述在nodejs中重用令牌检测的方法的实现可以是:如果恶意客户端生成新的AT RT对，并且合法用户向/request-token路由发出请求(不知道恶意客户端已经生成新的AT RT，这使得用户对无效)。除了检查AT RT是否有效之外，服务器还可以检查AT RT是否都是通过使用其秘密来签名，以及用户给出的RT是否存在于刷新令牌的数组中，如果发现，则意味着刷新令牌被重新使用，且令牌可能被泄露或窃取，这将删除所有发布的刷新令牌并要求用户再次登录。

我的问题是：
我应该使用哪种方法？这是实施身份验证的正确方法吗？
或者我应该使用另一种方法吗？（在这种情况下，请建议）

Answer 1

我希望晚一年还不算太晚。

>

对于选项 1，我假设您正在查看类似于本文中描述的实现的内容。值得指出的一点可能是，使用 UUID 作为 refreshToken 会使此类 refreshToken 暴露给恶意操纵，而不会在往返授权服务器的环形交叉路口传输期间检测到，而使用 JSON Web 令牌可以防止它

据我所知，正如您所指出的，来自 Auth0 文档的刷新令牌的选项 2 虽然不是防弹的，但与选项 1 相比具有天然优势，即不等到下一次登录，而是等到另一方的下一次请求 {legitimate_user，malichtml" target="_blank">ious_user} 强制合法用户注销并使恶意用户拥有的刷新令牌无效。

另一个考虑和问题是关于Auth0文档中关于刷新令牌的“自动重用检测”的实现细节和选项，这是对“刷新令牌轮换”的补充。Auth0文档提到了refreshToken的“家族”或“链”，每个都源于一个初始的refreshToken（例如，我想象与同一用户的每次登录相关，可能来自不同的设备或不同类型的浏览器）。因此，在数据库中，我们将此用户与多个refreshToken系列相关联，当我们检测到某个客户端请求试图使用一个不是系列中最新的refreshToken来尝试获取新的accessToken/refreshToken对时，我们将完全删除该特定系列。我觉得很明显，为了让这个“自动重用检测”起作用，也许我们不需要在实现这个过程中为这个家庭实际保留一个“链”，而只需要为这个家庭保留最新生成的refreshToken，但我的直觉告诉我，我可能遗漏了一些东西。