如何保护刷新令牌? [英] How to secure a refresh token?

问题描述

我使用 JWT 为我的应用验证用户身份.当用户登录时，他们会获得一个访问令牌和一个刷新令牌.为了保证刷新令牌的安全，我不会将其存储在客户端，而是将其与他们的帐户一起保存在后端，因此不容易访问.不过，我对刷新令牌的安全性感到困惑，这是我在阅读有关如何使用刷新令牌的在线资源时所理解的逻辑:

I'm using JWTs for authenticating users for my app. When a user logs in they are given an access token and a refresh token. To keep the refresh token safe, I don't store it on the client-side, but save it on the back-end with their account so it's not easy to access. I'm confused about the security of refresh tokens though, here's the logic that I'm understanding when I read online resources on how to use refresh tokens:

1. 验证
2. 在某处存储访问令牌 + 刷新令牌(在我的情况下，前端的访问令牌和后端的刷新令牌)
3. 执行 api 请求时，在 api 端验证访问令牌
4. 如果访问令牌过期，使用刷新令牌生成新的访问令牌+新的刷新令牌，将访问令牌发送回客户端
5. 像以前一样存储令牌...并重复

我担心的安全问题是，如果其他人(黑客)获得了访问令牌并使用它向 api 发送请求，如果令牌已过期，api 将使用刷新令牌来获取一个新的访问令牌 + 新的刷新令牌，并至少将访问令牌返回给黑客.

The security issue I'm worried about is if someone else (hacker) got a hold of the access token and they send a request to the api with it, if the token is expired the api will use the refresh token to get a new access token + new refresh token and return at least the access token to the hacker.

我阅读了这篇文章大约 5-6 次，并且我阅读了这篇 文章也多次就像关于这个主题的其他一些文章一样，他们都说了一些类似

I read this article about 5-6 times and I read this article a few times, as well as some other articles on the subject, they all say something along the lines of

确保安全地存储刷新令牌，因为它是长期存在的，access_token 是短暂的，所以没什么大不了的

make sure to store the refresh token securely because it's long lived, the access_token is short lived so not as big of a deal

但根据我上面描述的流程，访问令牌是否是短暂的并不重要，刷新令牌将用于获取新的访问令牌并永久访问.

But according to the flow I described above, it doesn't matter if the access token is short lived, the refresh token will be used to get a new access token and have access forever.

有什么我遗漏的吗?如果黑客持有过期的访问令牌，api 如何知道谁在发送请求?它仍然会使用刷新令牌发送一个新的.我是否应该以某种方式验证发送请求的人?

Is there something I'm missing? How would the api know who is sending the request if a hacker got a hold of the expired access token? it will still send a new one using the refresh token. Am I supposed to somehow validate who is sending the request?

更新

所以我知道当请求新的访问令牌时，我需要发送刷新令牌、客户端 ID 和客户端机密.我遇到的问题是，像以前一样，黑客可以向我的 API 服务器发送请求，服务器从黑客那里获取被劫持的访问令牌，它会看到它已过期，因此它将发送刷新令牌，以及将 clientID/client 机密(存储为环境变量)发送到 Auth API 并取回一个新的访问令牌/刷新令牌，这让我们回到了同样的问题.

So I do understand that when a new access token is requested, I need to send over the refresh token, the client ID, and the client secret. The issue I have with that is, like before, the hacker can send a request to my API server, the server gets the hijacked access token from the hacker, it will see that it's expired, so it will send the refresh token, along with the clientID/client secret (which are stored as environment variables) to the Auth API and get back a new access token / refresh token, which brings us back to the same issue.

更新 2

关于这个主题的一些有趣的问题:

some interesting questions on the subject:

1. 为什么 OAuth v2 有访问令牌和刷新令牌?
2. https://security.stackexchange.com/questions/87119/how-secure-are-expiring-tokens-and-refresh-tokens

根据第二个问题和答案，刷新令牌似乎不是一种更安全的维护访问方式，只是更容易检测到黑客，因为不断请求身份验证/刷新令牌并使对方的令牌无效.问题是这只会在 2 个用户同时尝试访问资源时发生 - 如果只有黑客碰巧在给定的时间段内处于活动状态，他将可以无限制地访问原始用户数据，直到原始用户尝试使用应用程序并访问受保护的资源

according to the second question and answer, it seems like the refresh token is not a more secure way to maintain access, it's just that it's easier to detect a hacker because auth/refresh tokens keep getting requested and invalidating the other's tokens. The issue with this is this will only happen if 2 users are simultaneously trying to access resources - if only the hacker happens to be active at a given time period, he will have unlimited access to the original users data until the original user tries to use the app and access protected resources

推荐答案

对于不同令牌的所有复杂性、它们的机制和它们的存储最佳实践，我不是专家(因此请参阅有关主题 - 蒂姆·哈迪 (Tim Hardy) 在下面的评论中对我的发现提出了出色而有力的反驳)，但在基于浏览器的应用程序中使用刷新令牌似乎是个坏主意.刷新令牌可以安全地存储在手机/其他设备上.您可能会在浏览器中使用仅 http cookie 或将令牌存储在内存中(参见下文)，但同样，我不确定这种方法的安全性(我不是说它不安全，我是说它不安全)我不知道有多安全)

I'm not an expert on all the intricacies of the different tokens, their mechanisms, and their storage best practices (so refer to other articles/experts on the subject - Tim Hardy poses an excellent and strong counterargument to my findings in the comments below) but it seems like a bad idea to use refresh tokens with browser based apps. Refresh tokens can be stored securely on phones/other devices. You could potentially use an http only cookie in a browser or store the token in memory (see more below) but again, I'm not certain on the security of this approach (I'm not saying its NOT secure, I'm saying I don't know how secure)

可以对此答案进行改进.虽然我个人不知道在浏览器存储中存储访问/刷新令牌所涉及的全部风险，但在 localstorage 中的短期(<10 分钟)访问令牌 + 内存中的刷新令牌可以极大地改善用户体验.这样，只要用户不进行硬刷新，或离开网站/网络应用程序，他们就会无限期地登录.

an improvement can be made to this answer. while I personally dont know the full extent of risks involved with storing access/refresh tokens in browser storage, a short lived (< 10 min) access token in localstorage + an in-memory refresh token can vastly improve the user experience. This way, as long as the user doesn't do a hard refresh, or navigate away from the website/webapp, they will be logged in indefinitely.

这篇关于如何保护刷新令牌?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！