Access token + Refresh token right approach?

Question

I'm trying to build RESTful API using NodeJS but having trouble understanding right way to authenticate user using tokens during api calls. After reading some blogs and articles I came up with these approaches:

Approach 1:

Access Token(AT) is JWT token containing unique userId as JWT payload. Expires in 1 day.
Refresh Token(RT) is random uuid using uuid npm package. Stored in database alongside user document.
Process:

1. When user signin/signup server issues new AT+RT.
2. If AT expires user sends request to /refresh-token route with AT+RT. Server check for correctness of RT by matching RT stored in db with RT given by user and decodes userId present in AT if AT is a valid JWT token. If every thing goes well RT is correct and AT is a valid JWT token, server issues a new AT and send it to user.

In above approach refresh token does not expires so if RT comes in hand of an malicious client then he can issue n number of access token and make calls to apis using them until a user signin again and server generates new pair of AT+RT. so RT in hands of attacker is of no use.

Approach 2:

Based on Request token rotation read on AuthO docs on refresh token
Access Token(AT) is JWT token containing unique userId as JWT payload. Expires in 1 day.
Referesh Token(RT) is JWT token. Expires in 4-5 month. Stored in DB as array of refresh tokens alonside user document.
Process:

1. When user signin/signup server issues new pair of AT+RT and pushes RT in array of refresh tokens stored in db.
2. When AT expires user requests to /request-token route with old pair of AT+RT and server generates new pair of AT+RT also stores

For above approach if tokens comes in hand of malicious client then server can detect it using following approach describe in below image.

Implementation for above approach of Reuse Detections of token in nodejs can be: if malicious client generates new AT+RT pair and legitimate user makes requests to /request-token route (unaware of malicious client has generated new AT+RT which make user pair invalidated). Server along with checking if AT+RT are valid can check if that AT+RT are both signed using by using its secret and if RT given by user is present in arrays of refresh token if found that means refresh token is reused and can be possible that tokens are leaked or stolen which deletes all that refresh tokens issued and asks user to login again.

my questions are:
Which approach should i use? and are that right way of implementing authentication?
OR Should i use another approach? (In this case plz suggest)

Answer 1

A year late is not too late, I hope.

1. For Option 1, I assume that you are looking at something similar to implementation described in this post. A minor point worthwhile to point out is perhaps that using of UUID as the refreshToken exposes such refreshToken to malicious manipulation without detection during the roundabout transit from and to the authorization server, while using JSON Web Tokens prevents it

2. From what I can see, Option 2 from Auth0 docs on refresh token, as you pointed out, although not bulletproof but has the natural advantage over Option 1 by not wait until the next sign in but the next request of the other party of {legitimate_user, malicious_user} to force the legitimate user to sign out and render the refresh token in possession of the malicious user ineffective.

3. An additional consideration and question is about implementation detail and options of 'Automatic Reuse Detection' from Auth0 docs on refresh token, which is the part that complements 'Refresh Token Rotation'. The Auth0 doc mentioned 'family' or 'chain' of refreshToken, each originated from an initial refreshToken (I imagine associated with each log in of the same user, perhaps from different devices or different types of browsers, for example). So in the database, we will have this user associated with multiple refreshToken families and when we detect some client request is trying to use a refreshToken that is not the latest in a family to try to obtain new accessToken/refreshToken pair, at which time, we remove that particular family entirely. I feel it is quite obvious that for this 'Automatic Reuse Detection' to work, perhaps we don't need to actually keep a 'chain' for that family in implementation of this but merely the latest generated refreshToken for that family, but my intuition is telling me I might have been missing something.