How about this way

[BeanVortex]

Hi
I implemented a new way of refresh tokens and I don't know that it is secure or optimized. this is how it works:

1- User logs in or sign up
2- Refresh token with expiration and Access token with no expiration created and sends to client
3- These created tokens, stored in database like this:

table: tokens
user_id | refresh_token | access_token
1 | some_token | some_token

4- When clients requests for an endpoint, it should send refresh_token and access_token in the header

5- Server checks if the refresh_token expired or not and also checks both refresh_token and access_token with stored ones if they are equal or not

6- If everything was OK, server generates new access_token and updates the table and sends back to client

By this way, access_tokens are used once. If client request for an endpoint and it was successful, server sends back a new access_token and the client for every next request alongside refresh_token, should send this new access token

[blackr1234]

4- When clients requests for an endpoint, it should send refresh_token and access_token in the header

5- Server checks if the refresh_token expired or not and also checks both refresh_token and access_token with stored ones if they are equal or not

The reason why we'd want to introduce refresh token is that we don't want access tokens to have a long expiry for security reasons. Without refresh token, the user needs to provide credentials to login again to get a new access token.
With a valid and unexpired access token, and optionally hit the database to check the user account status to see if it's disabled or has password changed, it is sufficient for the server to authenticate the user, so there is no need to send the refresh token. Sending both tokens also wastes bandwidth.
To be honest, if you are hitting the database anyway (stateful), why don't just use session ID? There is actually little to no reason to use access token at all.

[BeanVortex]

Oh thanks