The client can indeed save a round trip by proactively refreshing the access token. This does not necessarily revoke the existing access token. Many implementations do that, so your mileage may vary.
-- Justin On Nov 27, 2012, at 5:18 AM, Sergey Beryozkin wrote: > On 27/11/12 08:52, Guangqing Deng wrote: >> It seems that the client cannot know whether the refresh token should be >> used until a HTTP 401 error is returned from the resource server due to >> the expiration of current access token or some other reasons. However, a >> period of time cannot be ignored will be spent on obtain a new access >> token using the refresh token after the resource server returns a HTTP >> 401 error to the client, which may degrade the user experience since the >> real-time nature of the service cannot be guaranteed. Is a mechanism by >> which the client can check the validity of the access token (or the >> refresh token) in advance needed by Oauth? > > I believe an access token response may offer an expires_in parameter which > can provide some hint. Actually this raises an interesting question. > Suppose the client actually checks this parameter and decides to use > a refresh token it also has to pro-actively refresh its current token. > > IMHO this should work even if the access token has not expired yet and > effectively represents another form of a client-initiated revocation of the > access token ? It will mean a client which works with the "expires_in" > parameter can save a one round trip (the one which returns a failure in case > of the access token being expired) ? > > Does it make sense ? If it does, can some relevant wording make it into the > revocation token draft ? > > Cheers, Sergey > >> ------------------------------------------------------------------------ >> Guangqing Deng >> > ------------------------------------------------------------------------ >> > *From:* Justin Richer <[email protected]> >> > *To:* Sergey Beryozkin <[email protected]> >> > *Cc:* [email protected] >> > *Sent:* Wednesday, November 21, 2012 6:11 AM >> > *Subject:* Re: [OAUTH-WG] How the client can decide it is time to use >> > the refresh token >> > >> > There's no signaling regarding the validity of the refresh token from >> > the protected resource. In more distributed setups, the protected >> > resources know nothing about the refresh tokens because the PR never >> > sees them. In any case. the code path is fairly straightforward, even if >> > both tokens are expired: >> > >> > - client presents AT to resource >> > - resource returns data, AT worked >> > - [or] resource returns 400 error to client, AT didn't work >> > - client presents RT to auth server >> > - auth server returns new AT, RT worked >> > - [or] auth server returns 400 error to client, RT didn't work >> > - client has to go get a new auth grant from the resource owner, >> start over >> > >> > -- Justin >> > >> > >> > On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: >> > > Hi >> > > >> > > I'm looking for some guidance on how the client which already owns an >> > access token can decide, after getting HTTP 400 back from the resource >> > server it tries to access on behalf of the end user/resource owner, can >> > decide that the refresh token it has can now be used to get a new access >> > token. >> > > >> > > [1] refers to various error conditions but it is not obvious to me >> > that the same conditions (some of them) should or can be reported during >> > the actual client accessing the protected resource. >> > > >> > > My question is, what error condition, if any, from [1] should be >> > reported back to the client failing to access a protected resource due >> > to the access token being invalid or expired, so that it can help the >> > client who also owns the refresh token to decide it can use it now... >> > > >> > > Thanks, Sergey >> > > >> > > [1] http://tools.ietf.org/html/rfc6749#section-5.2 >> > > _______________________________________________ >> > > OAuth mailing list >> > > [email protected] <mailto:[email protected]> >> > > https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] <mailto:[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 > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
