JWT authentication – multiple refresh token flow
In my application, when users provide a username and password, they retrieve a access and refresh token. Let's call these a1 and r1 This is then stored on the client.
If a hacker manages to steal these tokens, they could use r1 to call the /refresh api endpoint in my application, which returns to them a new valid access token, e.g a2.
Whenever a user retrieves a refresh token, i.e they login or call /refresh, I store the token in an array in the database. The structure is for every one user, there can be multiple refresh tokens stored.
This approach above allows multiple devices to sign in and make requests for one particular user. If a genuine user notices there account has been hacked, they could change the password, deleting all refresh tokens in the database. This means that if a hacker somehow gained a valid refresh token, it would no longer provide a valid access token. They would have to re-authenticate, with the newly changed password to get new valid tokens (which they shouldn't be able to). The access token is short-lived, therefore would invalidate shortly after.
If the hacker and the genuine user both knew the password and were signed in on the same account, only the genuine user could change the password, as it required two factor authentication to change a password.
Also note that when /refresh is called in my API, only a new access token is sent back, not a new refresh token. This means it's impossible for a hacker to get a new refresh token unless they provide a username and password. This is to the best of my knowledge, so given the information above, please correct me if this is incorrect.
My question is that after reading multiple solutions on how to implement a solution like this, many mention the use of a device-id per refresh token, so one refresh token is associated with one device. However, as my client is a web browser, there is no offical way to retrieve a device-id. It would have to be generated and stored on the client in something like localStorage which could be hacked by a malicious user.
Due to this, I would like to keep the current solution I am using (without use of a device-id), and just store multiple refresh tokens per user in the database. However, I am unsure if this is a secure method. If there any flaws in this method, could you please point these out?
Also one additional query I have is that if my /refresh endpoint only provides new access tokens and not refresh tokens, then is it impossible for a user to generate their own new valid refresh token given their old access and refresh tokens. Perhaps this is done via a third party service, or is this just not a possibility. Is it impossible for them to get a new valid refresh token, as long as my /refresh endpoint doesn't provide one (which it doesn't)
