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?

Epicureanism

If either is compromised then of course you have an issue, but their purposes are different. The refresh token is for your interaction with an authentication server(I am authenticated, if I am authorized, give me a token to call service A), the jwt token is for your interaction with the services themselves (hello Service A, I am authenticated and authorized to call you). – Acephalous

This doesn't seem right. I don't think short-lived JWT's + refresh tokens is a separation of concern problem. I'm pretty sure the idea is to minimize the amount of time an attacker has access to a compromised JWT without damaging the user experience with frequent logouts. Apologies if I'm misunderstanding. – Epicureanism

Here's an article describing the usage pattern: auth0.com/blog/… – Acephalous

@KevinHooke thanks for the article! I think my question is in alignment with the article you provided. – Epicureanism

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.

Dickman

This sounds very good and all, but how do you know if the tokens are actually compromised? – Quinze

In most cases that's when a user reports a device missing (e.g. a lost mobile) and you have to assume the token has been compromised. In some cases, like in a banking scenario, you might also have some fraud detection which flags suspicious activity and revokes access as a precautionary measure. – Dickman

Well in that case it doesn't really solve the problem as I see it. You could potentially have compromised tokens without ever being aware of it. – Quinze

Nothing will solve the problem of having compromised tokens you're not aware of. If that's a big concern you might want to make all tokens short-lived to limit the potential for abuse. – Dickman

Yes, short lived tokens is something im trying to implement. On top of this another user suggested keeping track of device information and requiring new logins if the user is accessing the app from a new/different device. – Quinze