What is the advantage of using a Refresh Token instead of just the Access Token?

The advantage is greater security. But of course this will depend on the way you implement it. Obviously it's not because of using two tokens that your application will magically become more secure. :)

First of all, it is worth understanding that using only a stateless token to ensure access to your application is often unsafe, as it can be stolen - and this can hardly be prevented, as it can eventually be done at the level of hardware.

Thus, creating only a access token with a large expiration period (such as the one-week period) is a "security suicide", since (in most applications) no means of canceling a token before the end of its expiration period are implemented. Therefore, if a token is stolen, it is generally not possible to do anything until it has expired. And it brings problems.

So, you face a dilemma to solve this problem:

• Creating only the access tokens with a very long lifespan - which does not would be feasible at the security level, since if the token were stolen, there would be no way to cancel it in a timely manner.

• Creating only the access tokens with a very short lifespan - which does not would be feasible at the user experience level, since in the case of the theft of this token, there would be no way cancel it in a timely manner.

• Create a type of blacklist which allows you to list tokens that you don't want to be more accessible even before expiration. But this not seems to me a good option if you are using a stateless token in the first place, since it brings numerous problems. The biggest of them: end the need to use a stateless token , since it ceases to be stateless at the moment that each request you need to check whether the token is valid or not. Honestly, in this case it is more worth resorting to the good and Old Sessions.

• Create a mechanism with authentication based on two tokens, one access token and one refresh token. And this is more feasible, since it allows us to create a verifiable token with a long lifespan (the refresh token ) and a token to actually access our application with a short lifespan (the access token ).

Therefore, it is noted that the access token is used to de facto give access to the application, despite having a short lifespan. Thus, the application will check the validity of the refresh token to generate a new access token to the user, without the need to ask for their credentials.

Now it's up to you to decide how you will implement this. For the refresh token, Any Means are valid.

What I usually do is put a field count in the payload of the requestToken, which must be equal to the value count of a user's record in the database. If the number is different , I consider the refreshToken invalid and send the user to log in to generate the two tokens again.

In this case, if a user token is stolen, he or she can request the" cancellation " of the operation of all existing refresh tokens, simply by the application incrementing the count in its registration with the bank data. Thus, once the access tokens (which by definition have a short lifespan) have expired, the refresh token will no longer have validity, preventing the creation of new access tokens.

Note that when I say "short life time", I mean, at most, 5 minutes - and I still think a lot, because in the case of theft, the access token would take, at least, 5 minutes to lose validity, since the refresh token is only checked again upon expiration of the access token . The refresh token , in turn, can be longer. Usually I use 1 week, but it's up to you to decide this. :)