You should use the refresh token to get a new access token when it gets expired, so you'll need a column in the table where you store the user info (like username and password) to put the refresh token there.
The interesting thing about refresh tokens is that you don't have to request the users for their credentials since you just have to check the refresh token in your DB table with the one that is sent from the app.
In resume what do you need:
Add a column in the user info table to store the refresh token there.
Add a endpoint in the api to obtain a new access token from an existing refresh token.
You should find a way to store the refresh token in the client-side so you can send it when the access token gets expired.
Keep in mind that however, the refresh token should have an expiration time too, and it should be much greater than the expiration time of the access token, and when the refresh token expires it will be time to ask the user for his credentials.
The flow of the app would be like this:
The user authenticates whit his credentials and gets Access + Refresh tokens
The user uses the app accesing resources with the access token
After a certain amount of time the access token gets expired, when this happens the app requests the api for a new access token using the refresh token.
The following calls to the api uses the new access token.
I'm really sorry for my english, and if there is an error on my explanation please let me know!
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.
Hi!
You should use the refresh token to get a new access token when it gets expired, so you'll need a column in the table where you store the user info (like username and password) to put the refresh token there.
The interesting thing about refresh tokens is that you don't have to request the users for their credentials since you just have to check the refresh token in your DB table with the one that is sent from the app.
In resume what do you need:
I'm really sorry for my english, and if there is an error on my explanation please let me know!
Good Luck!
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.