Thank you for your effort to explain in great detail! I completely understand your English. ☺
I have a question. How do you store the refresh token on the client-side? Would that mean there will be some kind of 2nd user database aside from the user database in the api-side?
On the client-side you can store the refresh along with the access token in local storage, and in the api-side you just have to add a new column in the user info table (I suppose you have a table where do you have columns like 'username', 'password',...) I don't understand why you think that you have to create another database
The refresh token by itself does not provide any information about the user, (the access token yes), so I don't really see the problem in storing it in local storage. However, I understand your concerns.
The issue is about letting the JS have access to any kind of credentials. Traditional session cookies are usually http only for that matter. The same applies to access tokens or refresh tokens.
It's just about avoiding attack vectors.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for your effort to explain in great detail! I completely understand your English. ☺
I have a question. How do you store the refresh token on the client-side? Would that mean there will be some kind of 2nd user database aside from the user database in the api-side?
On the client-side you can store the refresh along with the access token in local storage, and in the api-side you just have to add a new column in the user info table (I suppose you have a table where do you have columns like 'username', 'password',...) I don't understand why you think that you have to create another database
But isn't storing Refresh Tokens on localStorage a bad practice because it can be tampered?
IMO you should NOT store those credentials in local storage. Refresh tokens are supposed to only be seen by servers, aren't they?
Take a look at Laravel Passport approach: uses traditional cookies to store an access token and a CSRF token.
The refresh token by itself does not provide any information about the user, (the access token yes), so I don't really see the problem in storing it in local storage. However, I understand your concerns.
The issue is about letting the JS have access to any kind of credentials. Traditional session cookies are usually http only for that matter. The same applies to access tokens or refresh tokens.
It's just about avoiding attack vectors.