jwt access token and refresh token flow

Viewed 360

here is my auth's flow:

  1. The user receives two tokens (access token with expiration time and refresh token without expiration time) after logging in
  2. for each user , The refresh token is stored in the database in a json column called refreshTokens(which is an array).
  3. on the client side, Both access token and refresh token are stored on the local storage.
  4. when user needs to be verified, If the access token is expired, a new access token is created using the refresh token and sent back to the user and keeps the user logged in.
  5. When the user logs out, the refresh token stored in the database (in the refreshTokens list) is removed.

my questions are:

  1. is this flow, secure?
  2. do i need to save refresh token on the cookie or is local storage good enough?
3 Answers

That flow is according to how OAuth works and how tokens can be stored in a secure way, so "yes" to both questions. The part that is missing is how the tokens are obtained in the first place: for that the Authorization Code grant type using PCKE is the preferred way, over the legacy Implicit grant type.

An important part of this flow being secured is that in point 4 you use the list of refresh tokens kept in the database to verify that the RT was not revoked. Other than that it looks ok. You can add more security by adding expiration times to refresh tokens. Then, even if the user doesn't actively log out (you don't clear RTs from the DB), the RT will not be usable after some time.

Keeping the tokens in local storage is good enough in my opinion.

Few stuffs that popped up in my mind while reading this :

  1. Refresh Token also needs expiration time. In fact, I consider refresh tokens as a double edge sword. Imagine a scenario where a person gets access to the refresh token, not only he gets access to the resources, he will practically gain more time with the resources. I prefer to re-generate refresh token along with access token when refresh token is being used to re-generate the access token. And, also set an expiry to it.

  2. It is cool to store the refresh token in database. However. I do have an alternative though, you can easily use RSA algorithm and then do token generation using private key and verify using public key. This is yo mitigate the scenario of needing to store the refresh tokens.

  3. On client side, local storage is a BIG NO from my side. What I prefer is that you use HttpOnly Cookies and set flag as true. HttpOnly Cookies are not rendered in JS and is sent to server securely as per Http protocol. This is fix the chances of compromising tokens.

Your rest concept of it is good enough.

Related