What's the point of the refreshToken interface?

We all know that pure jwt is stateless on the server, and only one jwt_secret on the server is responsible for pure mathematical verification. There is no need to access the database (whether it is a redis database or a sql database. As for those solutions that need to use redis to store jwt and some other information, that is session + jwt).

in that case, what is the meaning of the refreshToken interface? If the jwt has been leaked, the bad guys can call the refreshToken API with the leaked jwt to get the new token, as long as the bad guys don"t make mistakes, they can get the new token forever.

what"s the point of this compared to directly sign a jwt with a permanent time limit ?

< hr >

in the process of writing a question, I found the answer, but I have to wait for an hour of question review before I can submit the answer myself. Write directly under the question:

jwt this set of refreshToken has different schemes:

  1. the server has login interface / login, refresh token interface / refreshToken. Get a tokenA, when you log in. The token has expireAt. The client needs to pay attention to its own time and use the tokenA call / refreshToken to get the new tokenA before the tokenA expires. the only function of the / refreshToken interface here is that after the tokenA is leaked, we can pray to the Quan Yin Bodhisattva to let the hackers accidentally fail to call the / refreshToken interface in time
  2. the server has login interface / login, refresh token interface / refreshToken. When you log in, you get a tokenA (with expireAt) and a tokenB (without expireAt). The client can get a new tokenA at any time by calling / refreshToken with tokenB. the function of tokenB and / refreshToken interfaces here is to reduce the number of tokenB transmissions between networks and reduce the probability of being sniffed. After its practical https, tokenB and / refreshToken are basically meaningless .
  3. the server has three interfaces: / login / refreshToken / refreshRefreshToken. Both the tokenA and tokenB you get when you log in have expireAt. The function is a combination of 1 and 2.

if you already have https, scenario 2 doesn"t make sense, so just 1 is fine. The function of 1 is to "pray for Guanyin Bodhisattva-Guanyin: are you kidding me".

Mar.20,2021

what you said is problematic. The client needs to save two Token files, including accessToken and refreshToken, to use refreshToken refresh when accessToken fails.


Yes. Without https, you don't need refreshtoken, right?


No. Users will get accessToken and refreshToken after logging in. (both have expiration time), accessToken to request identification. RefreshToken users get a new accessToken, after the accessToken expires and update their expiration time at this time. If the user does not operate for a long time, the accessToken will also expire and the user will need to log in again.
first, https can be decrypted (you only need to install a certificate). Secondly, our API needs to have a signature mechanism to resist fake requests, and the expiration time of accessToken once again strengthens the security.

Menu