Yes, the client can keep two tokens and try using both of them if it wants to. I think that you're conflating revocation and expiration here, and missing a key use case: downscoping. Let's say the client gets an access grant for [A, B, C], and it gets RT and AT1 for those scopes. The client then wants to call a service with *only* scope B, so it sends RT in with scope B in the refresh request to get AT2 with that scope alone. AT1 is still valid, assuming it hasn't expired or otherwise been revoked. The client can choose which AT to present to the protected resources in different situations.
In all of these cases, it's completely up to the AS and the PRs whether or not any of the tokens in the wild are still valid. Your AS might decide that once a RT is used, it will simply throw away all existing AT's attached to that RT. That's totally a valid use case, and the client needs to be able to handle that (in the same way that it handles any invalid token). If you want the clients to explicitly throw out tokens, use the Token Revocation spec. -- Justin On Nov 27, 2012, at 10:41 AM, Sergey Beryozkin wrote: > On 27/11/12 15:29, Richer, Justin P. wrote: >> 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. >> > > I don't understand. > > So the client will still have the existing access token which may have not > been revoked, and then also another access token which was just returned in > response to the refresh grant request ? > > And if you mean that no actual revocation is actually done, why then have the > client worry about doing the proactive refresh ? > > I can imagine that may be that it will only be the actual refresh token > refreshed itself, but why keep the access token if the client has requested a > refresh ? > > Sergey > >> -- 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<jric...@mitre.org> >>>>> *To:* Sergey Beryozkin<sberyoz...@gmail.com> >>>>> *Cc:* oauth@ietf.org >>>>> *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 >>>>>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org<mailto: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 >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
