Correct. So the request would fail and you then re-authorize. You get a wasted request/response. But it doesn't cost as much as for an expired access_token.
Phil [email protected] On 2011-02-03, at 4:42 PM, matake@gmail wrote: >> since it expires in 3 to 6 months > > No, 6 hours or 3 months. > 3 months when user approved long-time access, 6 hours when not. > (Mixi has a checkbox on authorization page for that, so an client can have > both kind of refresh_tokens) > > The only way to know the refresh_token lifetime is try to refresh after 6+ > hours in this case. > > On 2011/02/04, at 9:35, Phil Hunt wrote: > >> I think this is a matter of frequency. Since an access token might expire >> frequently (e.g. in seconds rather than days or months), it is worth having >> the client calculate to see if a token has expired (by returning >> expires_in). It has the effect of saving the client/server a failed >> request/response round trip that might occur fairly frequently. >> >> In the case of the refresh_token, since it expires in 3 to 6 months, as in >> your example, it doesn't cost much to try the token and get an invalid_grant >> error in response forcing the client to re-authorize the grant. >> >> Still, I think the OAuth specification might be improved with some >> clarifying text (in section 1.4?). >> >> Phil >> [email protected] >> >> >> >> >> On 2011-02-03, at 4:19 PM, matake@gmail wrote: >> >>> Mixi, one of the biggest Japanese social network service, supports OAuth2 >>> with refresh_token. >>> The lifetime of refresh_token is 6 hours ~ 3 months depends on user's >>> decision on authorization. >>> >>> In that case, how can Mixi tell the lifetime of refresh_token? >>> Currently they just documented it in their API document. >>> >>> On 2011/02/04, at 5:43, William Mills wrote: >>> >>>> The general use case for refresh tokens is that they don't have a >>>> lifetime, although they can be invalidated by various things. >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On Behalf >>>>> Of Phil Hunt >>>>> Sent: Thursday, February 03, 2011 12:27 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] Refresh Token and Expires_in >>>>> >>>>> In 5.1 (draft 12), if a refresh_token is returned with an access_token, >>>>> what does expires_in refer to? Strict reading of the spec says it >>>>> refers to the access_token, but isn't lifetime of the refresh token as >>>>> important? Should there be a similar "refresh_expires_in"? >>>>> >>>>> Apologies if this was discussed before. >>>>> >>>>> Phil >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
