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
