Standardize refresh token expiration field in token responses

[pilcrowonpaper]

Hi,

Is there a reason why the expires_in field exists but an equivalent for refresh token doesn't? Something like refresh_token_expires_in. I couldn't find any discussion on it in past mailing lists. Currently, most implementations use refresh_token_expires_in while some use refresh_expires_in.

I'm not sure if this can be changed but I'd like to know if there's any background context to the decision.

[aaronpk]

Many servers have either unlimited length refresh tokens or refresh tokens with a dynamic expiration date.

In any case, the client can't do anything useful with the knowledge of the refresh token expiration time, so there's no point in telling it. If the refresh token expires, the only thing the client can do is start a new OAuth flow from scratch.

The refresh token also might expire before the scheduled expiration, even if there is a fixed expiration date. For example if the user revokes the application's access, or if they change their password, or any number of other events.

So even if the server did tell the client when the refresh token expires, it's actually when it "might" expire, and the client would have to handle an earlier expiration anyway.

This is all good context to add to the refresh token section so I will rename this issue so I can track that.

[aaronpk]

• The client has to handle the case of a refresh token expiring at any given time, the expiry is up to the AS, and can be scheduled or at an arbitrary time
• The only thing the client can do when the refresh token expires is start a new OAuth flow

[njwatson32]

Regarding "the client can't do anything useful with the knowledge of the refresh token expiration time", we (Google) have received feedback from several clients that they want to remind the user to reauthorize the application prior to the expiration of the refresh token in order to avoid a disruption of service. This is most common with applications that run in the background, e.g. analytics or monitoring tools, where the user is not typically around to be prompted to reauthorize when the RT does expire.

This isn't to say that clients are off the hook for handling RT expiration at "unexpected" times, but they should be allowed to optimize for the normal case when the RT expires when the AS says it will.

Given that OAuth 2.1 covers refresh token rotation (mandatory for public clients if tokens are unbound), and RT expiration can relate directly to that, it seems reasonable to include within the purview of this spec version.

(Side note: I agree with OP that refresh_token_expires_in is a reasonable name. A quick search suggests that Microsoft and Github already use this name, and we at Google are eyeing it too.)

[IvanAnishchuk]

:+1: on the last point. Already used that exact name refresh_token_expires_in in a custom implementation few years back.

[tiwarivikash]

Many clients such as Zoom inform users proactively that their session is going to expire in near future and they can choose to extend it before that.

[ObjectIsAdvantag]

+1 to add refresh_token_expires_in Cisco Webex already support it: https://developer.webex.com/docs/integrations#using-the-refresh-token and we need the OAuth specifications to include the field officially so that we can standardize internally on this exact name for other Cisco products.

[erincandescent]

In any case, the client can't do anything useful with the knowledge of the refresh token expiration time, so there's no point in telling it. If the refresh token expires, the only thing the client can do is start a new OAuth flow from scratch.

I don't think this is true, or what people mean by refresh_token_expires_in differs from my understanding. My understanding of refresh_token_expires_in is that in the normal case (token not revoked early), the client has until that time to invoke the refresh token grant with this token to receive a new access token and refresh token.

As an AS implementer, its very useful to be able to expire "stale" sessions; this means that refresh tokens must expire at some point. Clients need to know how often they must refresh their tokens in order to maintain the session. At present, the only advice they have on this is the expires_in value; but access token lifetime is often short. I might want e.g. access tokens to expire in 10 minutes but refresh tokens to expire in 7 days, but both me and the client would like it if they could only hit the token endpoint once every 7 days during periods of time where they're not actively using the RS but just need to maintain the session.

[njwatson32]

I think there are two concepts at play here:

1. How long is the user's authorization good for? Some AS may offer the user a choice (or mandate) to grant permissions only for a certain amount of time, especially for very sensitive data access (e.g. mail or biometrics).
2. How long is the credential itself valid, i.e. how often does the client need to hit the token endpoint to get a new RT.

Can a single refresh_token_expires_in field adequately address both use cases? The RT itself would always expire in min(rotation_cadence, user_authz_duration), so a single field would still be accurate, but clients might want to handle each case differently.

[njwatson32]

To close the loop here: Based on discussions at IETF 122, we are not including this in OAuth 2.1 but I will send out a draft of a standalone spec for RT and/or consent expiration.