Yeah, your way is much better, especially for client developers. All mixi access_tokens expire in 15 mins, I'm not sure the details of their security policy though. And there are no way to know the lifetime of refresh_token when client get an access_token.
On 2011/02/04, at 9:45, Eran Hammer-Lahav wrote: > Seems a bit odd to issue a refresh token for 6 hours. Why not just issue an > access token for 6 hours without any refresh token. > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of matake@gmail >> Sent: Thursday, February 03, 2011 4:43 PM >> To: Phil Hunt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Refresh Token and Expires_in >> >>> 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 >>> phil.h...@oracle.com >>> >>> >>> >>> >>> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 >>>>>> phil.h...@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
