Clarification using Refresh Token

[valh1996]

Hi,

I wonder how to use the refresh token using your example.

Normally using JWT, we get a token to authenticate and already the refresh token which allows us in case of 403 to ask for a new one.

However, according to your example, we need to be authenticated to access the /refresh route which gives us a new valid token.

So I would like to know how the frontend of my application can know when to request a new token via /refresh ?

Because in this case it's impossible to ask for a new token when my frontend intercepts a 403, because the token is already invalid, it's impossible to call the /refresh route.

Thanks
Val'

[valh1996]

One solution I'm thinking of would be to provide my frontend also with when the token expires so they can renew it in time. But in this case, I imagine that if the user is inactive during the time of the token validity (no requests), he will be forced to log in again anyway.

Edit : Seems to be confirmed here - #11 (comment)

[murraco]

Hi @valh1996,

Thank you for your interest in my code. As I mentioned in that comment, with this approach you have to keep track of the expiration time or refresh it on every request. If the user is inactive for a longer period than the token validity, then it's necessary to re-login. I know it's not a complete solution, but it solves the most common scenario based on my experience.

[valh1996]

Thank you for your answer @murraco. So in theory it should not be a problem on mobile either. The user will be forced to reconnect in that case. Maybe here it will be interesting to create a 4 or 6 digit password for example or to authenticate with FaceID for example.