Hi, I would assume the clients knows the scope required for a certain request (from documentation) and acquires the access token using the respective scope from the authz server. Given this assumption, 401 may only occur when the access token has expired.
regards, Torsten. Sergey Beryozkin <sberyoz...@gmail.com> schrieb: >I'd like to return to this thread. After learning about the refresh >grant supporting a client-driven down-scoping, the same question which >I >asked in the first place seems relevant again. > >If the clients gets 401 back while trying to access PR, how will it >know >how to react to it (use refresh grant with or without its optional >scope >parameter), is it because the access token has expired or is it because > >it has an invalid scope ? > >Thanks, Sergey > > >On 27/11/12 18:11, Sergey Beryozkin wrote: >> Hi Adam, >> >> thanks for sharing it, helpful, >> On 27/11/12 17:24, Lewis Adam-CAL022 wrote: >>> Hi Sergey, >>> >>> In my use cases the client actively monitors the expiration of the >AT >>> in order to request a new AT using the RT. We do this as you >>> suggested, because presenting an expired AT to the RS is a wasted >>> round trip and adds latency and degrades the user experience. Why >send >>> the AT if we know it's expired? >>> >> >> How do you know when the client is expecting a revocation and when a >> downscoping, I guess if the client includes and optional 'scope' >> parameter then it is down-scoping obviously, otherwise - revocation ? >> >> If that is the case then IMHO a refresh token grant request without a >> scope parameter might offer a shortcut for the client not to worry >about >> one more endpoint (to do with the revocation) ? >> >>> As to your other question, one reason to down scope an AT ... in my >>> use cases the AS issues access tokens for many different RS's. It is >a >>> security concern to send an AT to RS1 that has the ability to also >>> access protected resources at RS2 and RS3 and RSn, etc. So I make a >>> first request to get a "master" AT with a master RT, and then >>> immediately destroy the master AT and use the master RT to get a >>> down-scoped AT - one for each RS. This is inefficient though, and >I've >>> been nagging the WG to consider a draft to allow a client to request >>> an array of access tokens of different scopes. >>> >> OK, that makes it clearer. What I'm concerned about though, does the >> client need to be concerned or is it the job of AS to protect in >cases >> where a token with too many scopes is used to access a given RS which >> may delegate to a stricter RS ? >> >> I mean, is client expected to be well-behaved and know about the >> relationships between the master RS with the stricter RS1 & RS2 >parthers >> ? Seems not easy to make it interoperable... >> >> Guess I'm missing the point still >> >> Thanks, Sergey >> >>> These are just my experience, and as Justin mentioned, your millage >>> may vary. Hope it helps either way :-) >>> >>> adam >>> >>> -----Original Message----- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >Behalf >>> Of Sergey Beryozkin >>> Sent: Tuesday, November 27, 2012 10:26 AM >>> To: Richer, Justin P. >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] How the client can decide it is time to use >>> the refresh token >>> >>> On 27/11/12 15:48, Richer, Justin P. wrote: >>>> 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. >>>> >>> That is complex :-). Using a refresh token to downscope and keep a >>> number of access tokens is definitely beyond my imagination at the >>> moment, why would a client want to downscope its access token ? >>> >>> Is it basically described at: >>> >http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-03#section-3.10 >>> ? >>> >>> I'm still not getting though why access token with the richer set of >>> scopes needs to be explicitly downscoped by the client, is it >because >>> using a token with a richer set of scopes can lead to some >authorization >>> issues ? >>> >>> I was thinking that the down-scoping only makes sense during the >>> authorization code flow where AS downscopes what the client has >>> requested but obviously I'm only at the start of the learning curve >:-). >>> >>> >>> >>>> 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. >>>> >>> OK, that makes sense now. >>> >>> Thanks, Sergey >>> >>>> -- 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 >>> >>> >>> >>> >>> >> >_______________________________________________ >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
