When someone requests a new Refresh Token, should I update the new Refresh Token's expiry date?

When the client requests a new Refresh Token, should the Api update the new Refresh Token's expiry date or should I only send back a new Access Token and Refresh token, without updating the expiry date of Refresh Token?

I was following this guide to implement Refresh Tokens:

https://www.c-sharpcorner.com/article/jwt-authentication-with-refresh-tokens-in-net-6-0/

In the refresh-token endpoint of controller there is some code that updates the refresh token of the user, but it isn't updating the RefreshTokenExpiryTime as well, is this a mistake?

While in the login endpoint of the controller he is updating the refresh token of the user as well as the RefreshTokenExpiryTime. Shouldn't the same also be done in refresh-token endpoint of controller?

So, I understand the question in this way:

> A client is requesting a new Refresh Token from an Identity Provider. What should Identity Provider do about this?

Short answer

You need to create a new Refresh Token from scratch every time a Refresh Token is generated.

It makes sense as Refresh Tokens should be always valid for another refresh period. There is not much sense to not reset an expiration time of a new Refresh Token. Also, it's more complicated to implement such a logic in the Identity Provider.

Examples from Public Identity Providers

Microsoft Identity Platform

I can give an example of what Microsoft Identity Platform does in such a case:

> Refresh tokens replace themselves with a fresh token upon every use
>
> https://learn.microsoft.com/en-us/azure/active-directory/develop/refresh-tokens

Auth0

Also, there is an example from Auth0:

> The expiration period is renewed each time the refresh token is exchanged for a new access token within the interval.
>
> https://auth0.com/docs/secure/tokens/refresh-tokens/configure-refresh-token-expiration

Let's look into RFC 6749 "The OAuth 2.0 Authorization Framework"

+--------+                                           +---------------+
|        |--(A)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(B)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(C)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(D)- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--(E)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(F)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(G)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(H)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

It defines Refresh Tokens as:

> 1.5. Refresh Token
>
> Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires <...>
>
> Issuing a refresh token is optional at the discretion of the authorization server.
>
> A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
>
> https://www.rfc-editor.org/rfc/rfc6749#section-1.5

There are also rules on creating a new Refresh Token when refreshing an Access Token:

> 6. Refreshing an Access Token
>
> The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request.
>
> https://www.rfc-editor.org/rfc/rfc6749#section-6

Also, there are some notes on Refresh Token rotation:

> 10.4. Refresh Tokens
>
> ... authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.
>
> The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by unauthorized parties.
>
> https://www.rfc-editor.org/rfc/rfc6749#section-10.4

I read the RFC in that way:

• You can configure Authorization Server to generate Refresh Tokens. Or you can decide not to use Refresh Tokens at all.
• You can configure Authorization Server to issue a new Refresh Token every time an Access Token generated.
• Whenever a new Refresh Token is issued, it should be a new and fresh Refresh Token. It means, that new Refresh Token is issued exactly in the same way every time. There is no difference if it is a first Refresh Token or a second one.

If you're using refresh token rotation, then IMO you probably shouldn't reset the expiry on each new refresh token. The reason for this is so that stolen refresh tokens cannot be used indefinitely.

This same point is made in a draft IETF BCP (best current practice) for OAuth 2.0 for Browser-Based Apps - see here. Now this BCP is for a very specific scenario when using refresh tokens in browser based apps, but I think you could probably make the same underlying argument more broadly about refresh tokens.

Here's some of the key bits from the BCP -
> In particular, authorization servers:
>
> ...
>
> upon issuing a rotated refresh token, MUST NOT extend the lifetime of
> the new refresh token beyond the lifetime of the initial refresh token
> if the refresh token has a preestablished expiration time
>
> For example:
>
> * A user authorizes an application, issuing an access token that lasts 1
> hour, and a refresh token that lasts 24 hours
>
> * After 1 hour, the
> initial access token expires, so the application uses the refresh
> token to get a new access token
>
> * The authorization server returns a new
> access token that lasts 1 hour, and a new refresh token that lasts 23
> hours
>
> * This continues until 24 hours pass from the initial
> authorization
>
> * At this point, when the application attempts to use the
> refresh token after 24 hours, the request will fail and the
> application will have to involve the user in a new authorization
> request
>
> By limiting the overall refresh token lifetime to the lifetime
> of the initial refresh token, this ensures a stolen refresh token
> cannot be used indefinitely.