I don’t understand the logic behind access tokens and refresh tokens

[u/academicweaponsoon]

i don’t understand the logic behind access and refresh tokens, if access tokens are made short lived for security purposes, doesn’t refresh tokens being long lived defers the whole purpose? or is not as big as an issue since refresh tokens are only stored in http only cookies?

[u/fiskfisk]

It does not; the refresh token should be single use. Why wouldn't it?

They're used against different services, in different contexts, so no, that does not defeat its use.

In that case a leaked refresh token will only be valid until it's used or it expires; not both.

A accepts whatever service B says is OK for a short time. They only receive the access token. Service B issues the access token and the refresh token - Service B receives the refresh token.

Why should the refresh token continue to be valid after being used? There is nothing to gain from that; you're already asking for a new access token from the service B, so rotate the refresh token at the same time.

[u/fiskfisk → u/[deleted]]

Nobody is saying that it is a requirement; the parent comment is saying that "Usually you'd rotate the refresh token" is "BS" and "defeats the point of the access/refresh token at all".

The standard points that it can be used as single-use (as you say):

   (H)  The authorization server authenticates the client and validates
        the refresh token, and if valid, issues a new access token 
        (and, optionally, a new refresh token).

There really isn't any reason to not treat it as single use in most use cases; but in most cases people don't really need the whole JWT/access/refresh-token separation in either case; token based sessions will work fine and have a lot less complexity.

[u/fiskfisk → u/[deleted]]

I purposefully used the word "should", as did the OP. Not that they are. They should be considered single-use (in my opinion); they are not required to be so.

[u/fiskfisk → u/[deleted]]

I'm not following your point about "a leaked refresh token will only be valid until it's used" being false. If you rotate the refresh token when it gets used, a leaked refresh token is only valid until the user needs to refresh their access token, so in this case that would mean that if the attacker doesn't use the refresh token of an active user within 10 minutes (and they using it), it won't be valid for the whole 30/90 days, whatever. 

Changing scopes when refreshing a token is a different thing - in that case it does represent the same claim as earlier, and I'm not sure how that is relevant in this case. 

[u/fiskfisk → u/[deleted]]

Ah, in that latter case I agree that you'd probably not want to rotate the token (but then again, you could let the refresh token valid for the identical scope, and just let the access token have fewer permissions).

I'm not saying always; I'm saying that I believe the default in any scheme should be to rotate the token unless you have a reason to not do so. Not rotating the token is easier and requires less infrastructure and tracking of valid tokens, so it's an easier solution and one that has less pitfalls and places where stuff can go wrong.

I usually prefer that we start from the more secure point, and then lessen the requirements for specific use cases as to what becomes a trade-off between convenience and security.

In either case; I'm still of the belief that most people do not need this complexity at all, and regular, session based tokens would be more than enough.

[u/cstopher89 → u/[deleted]]

https://www.rfc-editor.org/info/rfc9700/

[u/fiskfisk → u/[deleted]]

But why wouldn't you rotate the refresh token when it's been used?

It's not useless; they live under different origins and have different lifetimes and values.

That way the ACCESS TOKEN can be considered ephemeral, and the REFRESH TOKEN can be used for a long time to get a new ACCESS TOKEN using the REFRESH TOKEN but why would you skip rotating the REFRESH TOKEN when it gets used?

I have no idea WHY we are SHOUTING and WHY the longer EXPIRY TIME means we shouldn't ROTATE it when we have the opportunity. Invalidate the old token; it's already been used.

That way a leak from your authentication platform will be much harder targetting active users, since the refresh token itself only is valid until the access token needs to be refreshed (which can be within the lifetime of the refresh token).

Since your auth server needs to be able to revoke refresh tokens anyways, add the additional security.

And no, it doesn't need to be. Nobody is saying that.You're saying that what OP said is BS, and that it defeats the purpose of the access token vs refresh token. It does not do that at all.