如何保护刷新令牌免受黑客攻击

Posted 2023-02-27

【中文标题】如何保护刷新令牌免受黑客攻击

【英文标题】：How to protect the refresh token from hacker

【发布时间】：2019-05-22 21:39:46

【问题描述】：

我在 Google 上搜索了很多关于如何保护 refresh_token 免受黑客攻击的信息，因为它将存储在浏览器的 local-storage/cookie 的某个位置，因此黑客可以轻松窃取这些令牌，而我无法找到一个正确的答案，所以我来到这里。

我知道access_token 将在更短的时间内过期，我们应该使用refresh_token 来获取新的access_token。但是如果黑客窃取了refresh_token的手段，他可以长期保持登录用户的身份，对吧？

有人说，你可以使用client_id 和client_secret 来保护它，但是黑客会访问API 的端点，它有client_id 和client_secret。同样，黑客可以轻松获得新的 access_token。

所以我没有办法保护黑客免于获得新的access_token。

谁能在这里指导我，我如何保护黑客不从浏览器的local-storage/cookie 访问刷新令牌？

【问题讨论】：

@dur 我必须拥有 refresh_token，否则用户会经常被注销。授权授权类型与非密码授权类型有何不同。

不推荐密码授予类型。安全问题太多。

【参考方案1】：

根据您的解释，您正在谈论基于浏览器的应用程序。如果此应用程序没有后端，那么您就没有安全的地方来存储您的长期令牌或客户端机密。

从 OAuth 2.0 的角度来看，这些称为 public clients。因此协议不允许他们拥有客户机密。所以他们有一个客户端 ID 和一个用于客户端身份验证（客户端标识）的重定向 URL。隐式流是一种适用于在浏览器上运行的 SPA 的关键流。根据规范，他们不会获得刷新令牌。原因是他们无法保护这些秘密。

但是，如果您有一个后端并且能够关联浏览器会话和后端存储，则可以使用一个流来提供刷新令牌并安全地存储它。但这需要您的应用程序架构支持此类（例如：- 浏览器会话和后端存储）。

此外，您可以使用身份服务器的已登录状态跳过登录，而不是让最终用户每次都登录。这也将依赖于身份服务器的浏览器 cookie 及其生命周期。例如，身份服务器可能有一个 24 小时有效的浏览器会话。因此，您的客户在一段时间内访问该应用程序时将看不到登录页面。

【讨论】：

我的应用程序有后端。成功登录后，我也在响应中发送 refresh_token ，这对任何人来说都很明显并且很容易破解。那么如何从后端安全地发送 refresh_token，以及前端如何安全地存储该 refresh_token。

@SuganthanMadhavanPillai 有一个后端很棒。这意味着您可以使用授权代码流。你不能从后端获得令牌响应吗？例如通过接收授权码响应的 servlet ？如果可能的话，您不必将刷新令牌重新发送到后端。如果前端直接联系 API，您的前端只需要获取访问令牌

【参考方案2】：

您可以尝试使用此库 Secure-ls 保护本地存储