以下JWT刷新令牌是否被认为是安全的？
我正在使用JWT进行身份验证为网站创建Web服务器。由于一旦准备就绪，这将是一个公开可用的系统，因此我想知道是否可以使用JWT访问和刷新令牌的以下身份验证流程被视为安全。 在这种情况下，假定一台服务器
在服务器启动时同时为Auth API和资源服务，它将生成“运行ID”，该“运行ID”是当前的UNIX时间戳和随机字符/UUID。这存储在内存中，任何重新启动都会生成一个新的。
登录或注册时，用户获得了初始的HTTPonly访问和刷新令牌。访问令牌的寿命短（约5分钟），刷新令牌的寿命更长（约2小时）。
访问令牌函数如正常，并包含用户ID。 刷新令牌具有USERID，服务器的运行ID及其独特的“ token ID”（类似于运行ID，每个刷新令牌唯一），
而不是在调用doken刷新端点的用户时，在调用新的访问和刷新令牌时，是在调用时如果满足以下标准，则需要授权的端点：
- 访问令牌已过期的
- 刷新令牌未
- 在刷新令牌中与当前运行ID相匹配的运行ID到期，而在当前的运行ID中，
- 刷新令牌的ID并未
在此事件中 列入黑名单。存在一个运行ID不匹配，或者令牌ID已放在黑人主义者身上，刷新令牌立即被认为是无效的。 令牌ID黑名单存储在内存中（例如运行ID）作为具有ID和到期时间的数组。 这允许用户注销和黑名单，该特定的刷新令牌从使用中。 这还允许任何系统管理员通过重新启动服务器而紧急使所有刷新令牌无效，因为RunID会更改。
我想知道是否可以将其视为安全的身份验证流
I am creating a web server for a site with authentication using JWTs. Since this is going to be a publicly available system once ready, I would like to know if the following authentication flow using JWT access and refresh tokens could be considered secure.
In this case it is assumed that one server serves both the auth API and resources
When the server starts, it will generate a "run ID" which is the current UNIX timestamp and random characters/UUID. This is stored in memory and any restart will generate a new one.
The user obtains an initial HttpOnly access and refresh tokens when logging in or registering. Access token has a short lifespan (~5 mins.) and refresh token has a longer lifespan (~2 hours).
The access token functions like normal and contains the userID.
The refresh token has the userID, the server's run ID and its own unique "token ID" (similar to run ID, unique for each refresh token)
Instead of the user calling a token refresh endpoint, new access and refresh tokens are made when calling an endpoint that requires authorisation if the following criteria are met:
- The access token has expired
- The refresh token has not expired
- The run ID in the refresh token matches up with the current run ID
- The refresh token's token ID isn't blacklisted
In the event that there is a run ID mismatch or the token ID has been put on a blackist, the refresh token is instantly considered invalid.
The token ID blacklist is stored in memory (like the run ID) as an array with the ID and expiration time.
This allows a user to logout and blacklist that specific refresh token from being used.
This also allows any system administrators to emergency invalidate all refresh tokens by restarting the server since the runID will change.
I would like to know if this can be considered a secure authentication flow
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我花了一段时间才了解令牌和您周围的动力发生了什么。我相信您在这里所做的比现实所需的要复杂得多，没有理由引入这种复杂程度。另请注意，其定义中的安全性是双边剑。这是诚信与机密性与可用性之间的永恒冲突。如果由于某种原因我们将系统的可用性拧紧，那么它不会以同样的意义将其视为安全，那么关闭计算机就不会被视为安全问题的解决方案。
话虽如此，让我们来看看您的解决方案。
您打算使用访问和刷新JWT令牌。此类系统中的注销应该如何？好吧，您简单地忘记了客户端上的令牌信息，或者如果您想在cookie中持有令牌 - 我相信您想根据“ httponly”标志获得，您可以清理cookie。就是这样。一旦信息从客户端传开，代币就无法轻易重新创建。无需将服务器上的令牌列入服务器上。 “忘记”他不使用的令牌符合客户的最大利益，并且一旦令牌消失，就没有第二份副本来替换它。
如果我们想处理像实时用户帐户锁定之类的方案，我们会使用令牌黑名单。如果您问我，这是一件昂贵的事情。
您仍然可以尝试将其黑名单刷新代币进行黑名单，但是假设您的身份验证机制可以访问用户池，则可以简单地检查数据库，如果用户被锁定，则无需在此处加缓存任何内容。
我注意到的下一件事是，您在这里所做的工作重新组装非常简单的HTTP会话处理方法，包括一旦服务器重新启动，就会失去会话。为什么不忘记令牌并使用简单的会话呢？
我也想知道，为什么您打算只有一个系统的实例。在高可用性年龄和使用JWT代币游戏中，将身份验证模块与逻辑分开并具有多个实例是完全有意义的。
另请注意，没有人能告诉您，您的工作是否安全，直到他们可以研究您的代码，配置和理想情况下 - 工作系统。有许多小块可以破坏解决方案。理想情况下，请查看可用的OWASP ASV（应用程序安全验证标准）在这里/a>看，兔子洞的深度。
It took me a while to understand what is going on with the tokens and your motivation around it. I believe what you did here is more complicated than reality requires and there should be little reason to introduce this level of complexity. Please also note, that security in its definition is a double edged sword. It's an eternal conflict between integrity and confidentiality VS availability. If for some reason we screw the systems availability then it will not be considered secure in the same sense, that turning a computer off is not considered a solution of security issues.
Having said that, let's look into your solution.
You intend to use access and refresh JWT tokens. How should a logout in such system look like? Well, you simply forget the token information on the client side or in case you want to hold tokens in cookies - which I believe you want to have based on "HttpOnly" flag - you can clean up the cookies. This is it. Once the information is gone from the client, the tokens can not be easily recreated. There is no need to blacklist the tokens on the server. It is in clients best interest to 'forget' the tokens he is not using and once the token is gone, there is no second copy to replace it.
We use token blacklisting in case we want to deal with a scenario like real-time user account locking. An expensive thing to implement if you ask me.
You can still try to blacklist refresh tokens, but assuming your authentication mechanism has access to the user pool, it can simply check in the database if the user is locked, no need to cache anything here.
Next thing I notice is that what you did here reassembles strongly simple Http Session handling including loosing the session once the server restarts. Why not forget the tokens and use a simple session instead?
I also wonder, why you intend to have only one instance of your system. In the High Availability age and playing with JWT tokens it would totally make sense to separate authentication module from logic and have more than one instance of both.
Please also note, that no one will be able to tell you, whether what you do is secure, until they can look into your code, configuration and ideally - working system. There are many small pieces that can break the solution. Ideally have a look into the OWASP ASVS (Application Security Verification Standard) available here to see, how deep the rabbit hole goes.