Why use JWT refresh token

Question

I'm not sure I understand the concept of refresh tokens. I know what they do - store them somewhere and whenever the access token expires, get a new access token with them.

It is obviously very important to not leak this refresh token because otherwise a third party could obtain a new access token with it. Therefore it need to be kept extra safe.

My question is: Why not just keep a long lived access token extra safe? Where is the difference in security?

Here is how this fact is described by auth0.com e.g.:

Benefit: Shorter windows of access for leaked access tokens (these expire quickly, reducing the chance of a leaked token allowing access to a protected resource)"

That does not make any sense to me. So the access token expires quickly and therefore it is "not bad" if it is leaked.

On the other hand it is very bad if the refresh token is leaked. So why not just try to keep the access token as safe as the refresh token and have the exact same outcome but one less token to manage?

Amandine

Possible duplicate of Why Does OAuth v2 Have Both Access and Refresh Tokens? – Paulie

Possible duplicate of JWT (JSON Web Token) automatic prolongation of expiration – Allottee

Answer 1

Sometimes it helps to think of the other side of the problem, e.g. the token issuer, not the token owner.

Example

Imagine someone's account has been removed / blocked by administrators.

With a token system, there is no way of invalidating all current tokens - the main point of JWT-style tokens is that possession of a valid token avoids centralised checks (in fact, the same is true of session cookies too really).

Problem with single token system

So to make this more efficient / convenient, in a single-token setup the lifespan of that token is sometimes quite large, meaning that owner (bearer) can have access for hours or days. Oh dear.

Solution: refresh token

A refresh token system, as they Auth0 guide said, allows this normal lifespan to be reduced (e.g. to minutes or seconds) before a refresh needs to be done. At this point, the server / centralised control can check if that account has been blocked or permissions are still good, and issue a new access token accordingly. It's still long enough to provide the performance gains of not calling the auth flow all the time (and of course not sending credentials)

Another use-case

A similar use case is the user losing a phone / device and they need to (effectively) revoke the token it had. Hope that helps a bit.

Liminal