0

I am not quite sure why refresh token is necessary while we can store simply a refresh-time which maps to the same thing as refresh token's expire date, and not have a refresh token at all.

I understand that having a long-lived access token is not good for many security reasons, hence refresh tokens are used.

But I can achieve the exact same behavior of a refresh token by having a short-lived access token with the following scenario: The authenticator can have its own database where it stores the access token itself, and a refresh time as a plain integer. And if the access token is expired, this refresh time is checked and access token is either reissued or not based on whether this refresh time is expired as well. You might say latency-wise this requires lots of unnecessary database calls, but this all can be cached on the server-side really easily, thus can be avoided.

So my question is simply: Why refresh tokens are necessary (and sending it back and forth to the client) while all the refreshing of a short-lived token (access token) can be handled with a simple refresh time integer?

Ahmet Yazıcı
  • 302
  • 9
  • 1
    Does this answer your question? [what's the point of refresh token?](https://stackoverflow.com/questions/10703532/whats-the-point-of-refresh-token) – Progman Mar 31 '23 at 20:52
  • Also check other questions like https://stackoverflow.com/questions/32060478/is-a-refresh-token-really-necessary-when-using-jwt-token-authentication – Progman Mar 31 '23 at 20:53
  • @Progman I don't think it does. Because as I stated, I know the security improvements refresh token brings in and fair enough. But why shouldn't I store a `expiry_date` in my database (cache it for performance reasons) and just work off of that? This way there is no way for refresh token to be captured as well and the security would be even further improved. – Ahmet Yazıcı Mar 31 '23 at 21:09

2 Answers2

0

Access tokens are non revokable in many distributed systems. To mitigate a risk of stealing of an access tokens, these tokens are short lived.

Clearly, short lived access tokens are a great inconvenience for customers. Hence, there is a refresh token idea - use the refresh token to get a renewed access token when the access token expires.

The main difference between access and refresh tokens is that the refresh token is revokable.

If a user is compromised, these steps will happen:

  • the system will revoke the refresh token (e.g. just delete it on the service side)
  • the access token will eventually expire on the client side
  • the client will call the system with revoked refresh token, and that step will fail to force the user to re authenticate
AndrewR
  • 1,252
  • 8
  • 7
0

I believe I found out the reason.

If access token is compromised in the scenario of storing into the database, even if access token is expired, the authenticator will always return back an access token since there is no way to understand whether the requester is malicious or not.

But if I send the refresh token to the client as well, and someone makes a request with only access token, the service will right away know whether it is coming from a malicious requester or not.

I guess then the question becomes, is there really such a case where access token can be compromised but the refresh token is not compromised, but that's a question for another post I believe.

Ahmet Yazıcı
  • 302
  • 9