Open pilcrowonpaper opened 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.
Hi,
Is there a reason why the
expires_in
field exists but an equivalent for refresh token doesn't? Something likerefresh_token_expires_in
. I couldn't find any discussion on it in past mailing lists. Currently, most implementations userefresh_token_expires_in
while some userefresh_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.