The advantage is greater security. But of course this will depend on the way you implement it. Obviously it’s not because you use two tokens that its application will magically become safer. :)
First of all, it is worth understanding that using only one 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 possibly be done at the hardware level.
Thus, create only one access token with a large expiration period (such as a one-week period) is a "safe suicide" since (in most applications) no means of cancel a token before the end of its expiration period. Therefore, if a token is stolen, it is generally not possible to do anything until it has expired. And that brings problems.
So you face a dilemma to solve this problem:
Create only access tokens with one very long life time - what nay would be safe, since if the token were stolen, we would not be able to cancel it in a timely manner.
Create only access tokens with one very short lifespan - what nay would be feasible at the level of user experience, since in the case of the theft of this token, there would be no way to cancel it in a timely manner.
Create a type of Blacklist that allows you to list tokens that you don’t want to be more accessible, even before it expires. But this nay it seems to me a good option if you are using a stateless token first, since it brings numerous problems. The biggest of them: end the need to use a stateless token, for it is no longer stateless at the time when each request you need to verify whether the token is valid or not. Honestly, in that case it’s worth having a good old session.
Create a mechanism with authentication based on two tokens, one access token and a refresh token. And this is more viable, as it allows us to create a verifiable token with great lifespan (the refresh token) and a token to actually access our application with a short lifespan (the access token).
Therefore, it should be noted that the access token is used to give de facto access to the application, despite having a short lifespan. Thus, the application will verify the validity of the refresh token to generate a new access token without the need to ask for your credentials.
Now it’s up to you to decide how you implement it. To refresh token, any means is valid.
What I usually do is put a field count in the payload of requestToken, which must be equal to the count of a user’s registration in the database. If the number is different, consider that the refreshToken is invalid and has the user log in to generate the two tokens again.
In this case, if a user token is stolen, he or she may request the "cancellation" of the operation of all refresh tokens existing, simply by increasing the count in your database record. So, once the access tokens (which by definition have a short lifetime) have expired, the refresh token will no longer be valid, preventing the creation of new access tokens.
Note that when I say "short lifespan," I mean, at most, 5 minutes - and I still think a lot, because in the case of theft, the access token it would take at least 5 minutes to expire, since the refresh token is checked again only upon expiry of the access token. The refresh token, in turn, it may be longer. Normally, use 1 week, but it’s up to you to decide this. :)
In your example, then, you change the value of
countevery week, right? (or if the user cancels). And in every request the client would be sending the two tokens to the server?– Rafael Tavares
It depends on your logic. But I don’t think that’s very much within the scope of this question, since you ask the perks, and not how to implement (because asking to implement the question would be too broad). It was just an example, the important thing is to understand why and how it works.
– Luiz Felipe