This question is SPA application specific like reactjs or vuejs.
when implementing jwt, refresh token is recommended for several reasons.
I found that the main reason of this is increasing security by keeping access token short-live(ex an hour) while refresh token set long-live(ex a year).
I also found that the safest place to store the tokens is cookie as it prevents XSS attack.
However, if we store both access and refresh token in cookie, both are sent over every http request and both can be stolen. then what is the point of having refresh token?
I know if we have auth server and resource server separately, only using refresh token to the auth server can reduce the chance to steal. But I have only one server (resource auth) and I don't think many apps implement auth server separately.
to sum up, question is is there any benefit to implement refesh token in terms of security?
It is all about limiting the impact of exploits.
OAUTH BEHAVIOURS
These are the standard OAuth behaviors in any environment, to protect bearer tokens.
An access token is short lived: I tend to use a 15 minute default. The bearer is the client and the recipient is the resource server.
A refresh token is the lifetime of a user session, eg 2 hours. The bearer is the client and the recipient is the authorization server. Only a client ever performs a token refresh.
A refresh token reduces the impact of stolen access tokens. A malicious party with a stolen access token cannot use it for long. Access tokens should also designed with least privilege to limit usage when they are stolen.
The refresh token is exposed in HTTP requests less often. Ideally, to use the refresh token the client also needs to provide a client credential that an attacker would not know.
BROWSER BEHAVIOURS
The browser is a particular client environment with its own best practices. Browser clients cannot usually safely supply a client credential:
Use HTTP-only SameSite=strict cookies to limit the impact of XSS exploits. Malicious JavaScript cannot then exfiltrate tokens from the browser. It can steal your data but a strong content security policy also helps prevent data exfiltration.
Encrypt the access and refresh tokens into separate cookies. When issuing the refresh token cookie, use a path so that it is only sent to a particular endpoint, eg /refresh, to reduce when that cookie is exposed.
SUMMARY
In some client environments you can use stronger defenses like proof of possession tokens. But that is not usually practical in the browser.
When the client environment restricts your options, follow the above type of standard behaviours, regardless of your particular setup.
In the browser, an XSS exploit can call all endpoints, send all cookies and steal your data. You mitigate as best you can by following best practices. Such attacks also end when the user navigates away from the app.