This question already has an answer here:

I use Refresh Token to handling expired Access Token, and in log out, I can remove Refresh Token from the database. Refresh Token must never expire (not sure) because the user can check "remember me".

So why should I use jwt in Refresh Token? Can it be just a random hash string? And should it have expiration time?

marked as duplicate by Josef, Xander, Steffen Ullrich, Jeroen - IT Nerdbox, Matthew Apr 17 at 7:35

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


Can it be just a random hash string?

Yes, it can be any random string. You just have to ensure that it cannot be randomly generated or guessed.

So why should I use jwt in Refresh Token?

jwt has it's own pros and cons.
The main advantage being it's stateless; And you don't need any storage.
However, the downside is the security depends on just one key. If it's compromised, the whole system is compromised.

It depends on your architecture and use-case. Both jwt and random hash string are already used successfully in many production application. Choose as per your need and resources.

And should it have expiration time?

Seems you're considering to use it. :)
Since, it's used to get a new access token in case it is expired, refresh_token must have long expiry time. With above, there is concern for abuse of the refresh_token. To mitigate it, we can take some measures. Let's take a look at the OAuth 2.0 specification. OAuth RFC-6749

the authorization server could employ refresh token
rotation in which a new refresh token is issued with every access
token refresh response. The previous refresh token is invalidated
but retained by the authorization server. If a refresh token is
compromised and subsequently used by both the attacker and the
legitimate client, one of them will present an invalidated refresh
token, which will inform the authorization server of the breach.

Would love to know whether you used jwt for your purpose.
(Do write an answer/comment here in future)

  • Thanks for your answer. I get some good ideas, but still, there are some ambiguous parts. First of all, you say: And you don't need any storage. This is about the Access Token, not the Refresh Token. Because I must invalidate Refresh Token in the logout functionality, so I must save it in db. And about your reference from OAuth, would you please give me more information in the form of an example? – Vahid Najafi Apr 11 at 7:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.