使用 JWT 令牌认证时是否真的需要刷新令牌? [英] Is a Refresh Token really necessary when using JWT token authentication?

问题描述

我正在引用另一篇 SO 帖子，该帖子讨论了在 JWT 中使用刷新令牌的问题.

我了解 JWT 令牌身份验证，但我对如何使用刷新令牌感到有些困惑.

我希望我的 JWT 身份验证具有以下属性:

1. JWT 令牌的有效期为 2 小时.

2. 客户端每小时刷新一次令牌.

3. 如果用户令牌未刷新(用户处于非活动状态且应用未打开)并过期，则他们需要在想要恢复时登录.

我看到很多人声称使用刷新令牌的概念使这成为更好的体验，但是，我没有看到这样做的好处.管理它似乎增加了复杂性.

我的问题如下:

1. 如果我要使用刷新令牌，那么为该令牌的良好实践设置一个长期到期是否仍然有益?
2. 如果我要使用刷新令牌，该令牌是否会与 userId 和/或 JWT 令牌一起保存?
3. 当我每 1 小时更新一次令牌时，这是如何工作的?我要创建一个接受我的 JWT 令牌或刷新令牌的端点吗?这会更新我的原始 JWT 令牌的到期日期，还是创建一个新令牌?
4. 鉴于这些详细信息，是否需要刷新令牌?似乎如果用户只是使用 JWT 令牌来获取新令牌(根据上面的链接)，则刷新令牌已过时.

解决方案

让我稍后再回答您的问题，并从实际讨论刷新令牌的整个目的开始.

所以情况是:

用户打开应用程序并提供他的登录凭据.现在，该应用很可能正在与 REST 后端服务进行交互.REST 是无状态的，无法授权访问 API.因此，到目前为止，在讨论中，没有办法检查授权用户是否正在访问 API 或只是一些随机请求正在通过.

现在为了能够解决这个问题，我们需要一种方法来知道请求来自授权用户.所以，我们所做的是引入一种叫做访问令牌的东西.所以现在一旦用户成功通过身份验证，他就会获得一个访问令牌.这个令牌应该是一个长且高度随机的令牌(以确保它不能被猜到).这就是 JWT 出现的地方.现在，您可能/可能不想在 JWT 令牌中存储任何特定于用户的详细信息.理想情况下，您只想在 JWT 中存储非常简单、极其不敏感的细节.用于检索其他用户详细信息(IDOR 等)的 JWT 哈希操作由 JWT(正在使用的库)本身负责.

所以，现在，我们的授权访问问题已经解决.

现在我们谈论一个攻击场景.假设使用上述所有用户 Alice，使用该应用程序，拥有授权访问令牌，现在她的应用程序可以向所有 API 发出请求并根据她的授权检索数据.

假设 SOMEHOW Alice 丢失了访问令牌，或者换句话说，对手 Bob 可以访问 Alice 的访问令牌.现在，尽管未经授权，Bob 可以向 Alice 授权的所有 API 发出请求.

我们不想要的东西.

现在解决这个问题的方法是:

1. 要么检测到发生了此类事情.
2. 减少攻击窗口本身.

单独使用访问令牌，很难实现上述条件 1，因为无论是 Alice 还是 Bob，都使用相同的授权令牌，因此无法区分来自两个用户的请求.

所以我们尝试实现上面的 2，因此我们为访问令牌的有效性添加了一个过期时间，假设访问令牌在t"(短暂)时间内有效.

它有什么帮助?好吧，即使 Bob 拥有访问令牌，他也只能在有效时使用它.一旦它到期，他将不得不再次取回它.现在，当然，你可以说他可以像第一次得到它一样得到它.但话又说回来，没有什么能比得上 100% 安全！

上述方法仍然存在问题，并且在某些情况下是不可接受的.当访问令牌过期时，它会要求用户输入他的登录凭据并再次获取授权访问令牌，至少在移动应用程序的情况下，这是一种糟糕的(不可接受的)用户体验.

解决方案: 这就是刷新令牌的用武之地.它也是一个随机的不可预测的令牌，首先也与访问令牌一起发布给应用程序.这个刷新令牌是一个非常长的特殊令牌，它确保一旦访问令牌过期，它就会向服务器请求一个新的访问令牌，从而消除用户重新输入其登录凭据进行检索的需要一个新的授权访问令牌，一旦现有令牌过期.

现在您可能会问，Bob 也可以访问刷新令牌，类似于他破坏访问令牌的方式.是的.他可以.但是，现在很容易识别这样的事件，这在单独使用访问令牌的情况下是不可能的，并采取必要的措施来减少造成的损害.

如何?

对于每个经过身份验证的用户(通常在移动应用的情况下)，都会向应用发出一对一映射的刷新令牌和访问令牌对.因此，在任何给定的时间点，对于单个经过身份验证的用户，将只有一个访问令牌对应于刷新令牌.现在假设如果 Bob 破坏了刷新令牌，他将使用它来生成访问令牌(因为访问令牌是唯一有权通过 API 访问资源的东西).一旦 Bob(攻击者)请求使用新生成的访问令牌，因为 Alice(真正的用户)的访问令牌仍然有效，服务器就会将此视为异常，因为对于单个刷新令牌，在一个时间.识别异常后，服务器将销毁有问题的刷新令牌，并且与所有相关联的访问令牌也将失效.从而防止对任何需要资源的授权的任何进一步访问，无论是真实的还是恶意的.用户 Alice 将被要求再次使用她的凭据进行身份验证并获取一对有效的刷新和访问令牌.

当然，您仍然可以争辩说 Bob 可以再次访问刷新和访问令牌并重复上面的整个故事，可能会导致对真正的真正客户 Alice 的 DoS，但再一次没有像100% 安全.

作为一个很好的做法，刷新令牌应该有一个到期时间，尽管时间很长.

I am referencing another SO post that discusses using refresh tokens with JWT.

JWT (JSON Web Token) automatic prolongation of expiration

I have an application with a very common architecture where my clients (web and mobile) talk to a REST API which then talks to a service layer and data layer.

I understand JWT token authentication, but I am a little confused at how I should use refresh tokens.

I want my JWT authentication to have the following properties:

1. JWT Token has an expiration of 2 hours.

2. The token is refreshed every hour by the client.

3. If the user token is not refreshed (user is inactive and the app is not open) and expires, they will need to log in whenever they want to resume.

I see a lot of people claiming to make this a better experience using the concept of a refresh token, however, I don't see the benefit of this. It seems like an added complexity having to manage it.

My questions are the following:

1. If I WERE to use a refresh token, wouldn't it still be beneficial to have a long term expiration for good practice on that token as well?
2. If I WERE to use a refresh token, would that token be persisted with the userId and/or JWT token?
3. When I update my token every 1 hour, how does this work? Will I want to create an endpoint that takes in my JWT token or my refresh token? Will this update the expiration date of my original JWT token, or create a new token?
4. Is there the need for a refresh token given these details? It seems that If the user is just using a JWT token to grab a new token (per the link above) then the refresh token is obsolete.

解决方案

Let me come to your questions a little later down the line and start by actually discussing the whole purpose of a refresh token.

So the situation is:

The user opens the app and provides his login credentials. Now, most probably the app is interacting with a REST backend service. REST is stateless, there isn't a way to authorize access to the APIs. Hence, so far in the discussion, there is no way to check if an authorized user is accessing the APIs or is just some random requests coming through.

Now to be able to solve this problem, we need a way to know that the requests are coming from an authorized user. So, what we did was to introduce something called an access token. So now once the user is authenticated successfully, he is issued an access token. This token is supposed to be a long and highly random token (to ensure that it can not be guessed). This is where the JWT comes into the picture. Now you may/may not want to store any user-specific details in a JWT token. Ideally, you would want to just store very simple, extremely non-sensitive details in the JWT. The manipulation of the JWT hash to retrieve other user's details (IDOR etc.) is taken care of by JWT (the library being used) itself.

So, for now, our problem with authorized access is solved.

Now we talk of an attack scenario. Let's say using all of the above user Alice, using the app, has the authorized access token and now her app can make requests to all the APIs and retrieve the data as per her authorization.

Assume that SOMEHOW Alice loses the Access Token or put another way, an adversary, Bob, gets access to Alice's access token. Now Bob, despite being unauthorized, can make requests to all the APIs that Alice was authorized to.

SOMETHING WE IDEALLY DON'T WANT.

Now the solution to this problem is :

1. Either detect that there is something of this sort happening.
2. Reduce the attack window itself.

Using just the access token alone, it is hard to achieve condition 1 above, because be it Alice or Bob, it's the same authorized token being used and hence requests form the two users are not distinguishable.

So we try achieving 2 above and hence we add an expiration to the validity of the access token, say the access token is valid for 't' (short-lived) time.

How does it help? Well, even if Bob has the access token, he can use it only while it is valid. As soon as it expires, he will have to retrieve it again. Now, of course, you could say that he can get it the same way he got it the first time. But then again there's nothing like 100% security!

The above approach still has a problem and in some cases an unacceptable one. When the access token expires, it would require the user to enter his login credentials and obtain an authorized access token again, which at least in case of mobile apps, is a bad (not acceptable) user experience.

Solution: This is where the refresh token comes in. It is again a random unpredictable token that is also issued to the app along with the access token in the first place. This refresh token is a very long-lived special token, which makes sure that as soon as the access token expires, it requests the server for a new access token, thus removing the need for the user to re-enter his login credentials to retrieve a new authorized access token, once an existing one has expired.

Now you may ask, Bob can have access to the refresh token as well, similar to the way he compromised the access token. YES. He can. However, now it becomes easy to identify such an incidence, which was not possible in the case of an access token alone, and take the necessary action to reduce the damage done.

How?

For every authenticated user (in case of a mobile app, generally), a one to one mapped refresh token and access token pair is issued to the app. So at any given point in time, for a single authenticated user, there will be only one access token corresponding to a refresh token. Now assume that if Bob has compromised the refresh token, he would be using it to generate an access token (because access token is the only thing which is authorized to access resources through the APIs). As soon as Bob (attacker) requests with the newly generated access token because Alice's (genuine user) access token is still valid, the server would see this as an anomaly, because for a single refresh token there can be only one authorized access token at a time. Identifying the anomaly, the server would destroy the refresh token in question and along with it all, it's associated access tokens will also get invalidated. Thus preventing any further access, genuine or malicious, to any authorization requiring resources. The user, Alice, would be required to once again authenticate with her credentials and fetch a valid pair of a refresh and access tokens.

Of course, you could still argue that Bob could once again get access to both refresh and access tokens and repeat the entire story above, potentially leading to a DoS on Alice, the actual genuine customer, but then again there is nothing like 100% security.

Also as a good practice, the refresh token should have an expiry, although a pretty long one.

这篇关于使用 JWT 令牌认证时是否真的需要刷新令牌?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！