oauth-wg / oauth-v2-1

OAuth 2.1 is a consolidation of the core OAuth 2.0 specs
https://oauth.net/2.1/
Other
52 stars 27 forks source link

Expand on reasons for not including expires_in in the token response #187

Open pilcrowonpaper opened 2 months ago

pilcrowonpaper commented 2 months ago

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 commented 2 months ago

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.