仅在HTTP cookie中使用JWT进行身份验证而不刷新令牌
即将到来的问题的座右铭是“我不知道我不知道什么”。我想知道身份验证实现是否存在不利因素或安全风险。
现在，我只将一个JWT存储在一个HTTP cookie中，以便将它从客户机(React应用程序)发送到服务器(Spring /Kotlin应用程序)。这消除了XSS漏洞。
JWT遵循基本原则(编码秘密、过期日期、发行者检查等)。服务器有servlet过滤器，用于检查每个请求的有效性。当通过客户端登录时，服务器使用有效的JWT进行响应：
客户端将在每个请求中发送其cookie，服务器的servlet过滤器将进一步检查每个请求的有效性。当这些检查为阳性时，用户将通过Security进行身份验证。
如上所述，JWT将在1小时、1天或任何配置之后过期。这就是为什么我需要以某种方式更新它。现在，我决定不再使用刷新令牌并将其放置在客户端的本地存储中，而是向服务器发出一个小请求，并创建一个新的JWT，它再次通过响应发送回来：
同样，当调用refresh端点时，servlet过滤器将检查有效性。因此，只有已经通过身份验证的用户才会以这种方式接收新的JWT令牌。一些无效的JWT将不会接收新的JWT。我在间隔内从客户端调用这个端点，因此定期延长cookie中JWT的过期日期。
我知道的是：
- 使用当前的刷新机制，访问令牌可以无限期有效(当用户定期登录时)。
- 我也不会在数据库中保存有效的令牌或会话，因此我不能以这种方式使特定的用户会话“全局”失效，因为cookie是唯一的真相来源。但是这与刷新令牌无关，我可以通过用户ID创建这样的白名单/黑名单。
如果真的有什么不好的事情发生，我仍然可以
- 将所有JWT的过期日期设置为0，因此每个经过身份验证的用户在下一次发送请求时都将未经过身份验证。
- ...or I可以更改JWT秘密，不再有任何请求经过身份验证。
我的问题是:我正在做的事情(替换cookie中的JWT )还有更多的缺点吗？
回答 1
Software Engineering用户
发布于 2021-05-29 18:22:09
这是一个基于理论观点的答案。
你正在设计的是不标准的.非标准的安全性总是一种风险。你必须决定你的风险偏好是什么。如果您在实现中遇到问题，您的所有用户都可能暴露或用户数据等风险。您愿意承担这个风险吗？这是你的选择，不是我的。
已经开发了一些标准，如基本安全性、oauth2流、Kerberos等，以标准化登录流以避免可能存在风险的实现。还可以实现诸如单点登录和不同服务之间的身份验证等功能。
有很多事情是危险的，不具体涉及你的流动，例如：
- 什么都是TLS吗？
- JWT中是否有敏感信息？
- 什么密码策略，我们可以枚举登录吗？
- JWT正确签名吗？签名密钥是如何存储的？
- CSRF和CORS是否到位？
我不喜欢的是你的/refresh解决方案。在标准oauth2流中，您一直对资源服务器执行请求，直到服务器用401 UNAUTHORIZED响应客户机，然后获取刷新令牌并尝试刷新，然后重新执行原始请求。如果刷新失败，它们将被正式注销。如果它们刷新和重做请求，而请求失败，则它们将被注销。
当您在离开一段时间后访问该站点时，客户端将检查是否存在刷新令牌，如果它存在，则尝试刷新，然后您可以继续删除它。否则你需要重新登录。
在您的解决方案中，您需要一个经过身份验证的用户来定期轮询刷新端点以获得一个新的令牌。
这一解决办法的问题：
- 如果我离开页面，在JWT过期后返回，我无法刷新，我需要重新登录。这意味着我一天可能需要重新登录几次。
- 过多的流量需要，对移动用户不好，或者当你连接不好的时候。
- 如果服务器被重新部署，花费的时间太长，那么每个人都可能无法刷新，并且所有的服务器都会被注销。
- 理解何时需要刷新令牌的复杂逻辑。我能送一张旧的代币，让它恢复元气吗？我能给一些旧的代名词钢一下并使它更新吗？
其他评论：
我觉得这更像是一个基于会话的登录，包含一个JWT。这个解决方案是如何扩展的？这就是为什么您通常分离并拥有一个发行者服务器，这纯粹是问题和验证令牌。这样您就可以在多个服务器和微服务上添加。
这结束了我的回答，但不看实现，这是理论上我可以威胁模型围绕这一点。
https://softwareengineering.stackexchange.com/questions/426729
复制相似问题
腾讯云开发者
