How is a refresh token more secure than a long lived JWT?

Question

I'm having a hard time understanding the use of refresh tokens when using JWT's with naturally insecure clients (browsers, mobile phones, etc.).

To me, it seems naive to think that if a JWT has been compromised the refresh token has not also been compromised.

The attacker essentially has a source of unlimited JWT's as long as the refresh token remains valid. Even if you invalidate used refresh tokens the attacker still has the upper hand if they implement a slightly more aggressive refresh policy. How is this different from a compromised long-lived JWT?

When using a long-lived JWT the attacker can only continue getting valid JWT's if they have the ability to continuously exploit whatever vulnerability gave them the JWT in the first place. With refresh tokens, they can get the JWT through a vulnerability once and then get new JWT's with impunity however they like. This seems either equally secure or perhaps even less secure than long-lived JWT's.

What am I missing?

Answer 1

Refresh tokens are revokable. If they are compromised they can immediately be revoked on the authorization server and no more JWTs will be produced.

JWTs, on the other hand, are usually self-contained. That means they are validated locally by checking a token's digital signature. Once issued they can not be revoked. That's why they should never be long-lived.

If both the JWT and refresh token get compromised, you would revoke the refresh token and the attacker would not get access once the JWT has expired. This might mean the revocation is not immediate.

Another option is to use long-lived reference tokens instead of the JWT and refresh token. In this case, immediate revocation is possible. The downside is that each use of the reference token needs to be validated against the authorization server.