What is the point of having a refresh token if it can be as easily stolen as an access token on client-side/JavaScript applications (SPA/PWA)?

Question

From my understanding, the point of having a refresh token and short lived access tokens is to mitigate the consequences of having the access token stolen. This way, if this happens, the attacker will only be able to use it for a very short duration of time.

However, because refresh tokens and access tokens are usually stored in the exact same way on client-side/JavaScript apps, usually on local storage or session storage, the effort/difficulty of stealing the refresh token is the same as the access token, which means that an attacker can steal the refresh token as easily as he would be able to steal the access token and thus request as many access tokens as he wants until the refresh token expires.

If this is true, then what real difference is there between having a long lived refresh token and a short lived access token versus just having a long lived access token on client-side/JavaScript apps? You could store the refresh token in a secure http-only cookie to prevent XSS attacks but you could do the exact same thing with access tokens.

Answer 1

You're correct. If refresh token is stored in same vault as access token, the distinction between the two is diluted.

In https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/ is a phrase "Refresh tokens are usually subject to strict storage requirements to ensure they are not leaked".

If your application is compromised by attacker, you will anyway be in trouble. Still there exist scenarios where having separate token for access and refresh is beneficial as the attacker cannot access the refresh token.

Again, there are number of scenarios where the phrase from question "attacker can steal the refresh token as easily as he would be able to steal the access token" holds true.

To answer the original question is: Every improvement in security is an improvement no matter how small they are!

Answer 2

I believe Jari's answer says it all. I had the exact same question, and this answer really clarified it.

If you don't mind, I'd like to add an extra note for future readers from my personal notes:

Refresh Tokens, even when stored in a browser (which means they're stealable just like a long-lived Access Token), still bring some benefits.

The first benefit is that Refresh Tokens, in this scenario, should be exchanged with the API only in a specific request: when you want to generate a new Access Token. This means RTs are attached to a few requests only.

The Access Token, on the other hand, is exchanged in every request.

If someone is sniffing your network, it's harder to steal a token that's attached to a few requests, than steal a token that's attached to every request.

There's also a second benefit. RTs are usually stored in a database and attached to a certain user, which means they can be easily revoked at anytime if they're leaked. Which is not true for ATs built with eg. JWT, where they cannot be revoked until they expire.