DEV Community

Discussion on: What is the usual flow in authenticating a Client Application with a Token based REST API?

Collapse
jjjjcccjjf profile image
endan Author

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?

Collapse
lims profile image
Lucas

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

Thread Thread
jjjjcccjjf profile image
endan Author

But isn't storing Refresh Tokens on localStorage a bad practice because it can be tampered?

Thread Thread
skyrpex profile image
Cristian Pallarés

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.

Thread Thread
lims profile image
Lucas

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.

Thread Thread
skyrpex profile image
Cristian Pallarés

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.