Yes, exactly right. The client gets a hint about the AT lifespan, but must
always handle the error response too. If the AT fails with a 401 then you try
a refresh. If the refresh fails and you get a 401 response then you
re-authenticate the user. Other 4XX error codes mean something different of
course.
________________________________
From: Sergey Beryozkin <sberyoz...@gmail.com>
To: Justin Richer <jric...@mitre.org>
Cc: oauth@ietf.org
Sent: Wednesday, November 21, 2012 6:18 AM
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh
token
Hi
On 21/11/12 14:11, Justin Richer wrote:
> 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.
I was just asking how the client decides it can use the refresh token, and
> 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
>
the answer seems to be that whenever it gets 400 after presenting AT to
resource it should try to use RT next to get a new AT, I guess it was
not really obvious to me though now that I think about it, it makes
sense, 400 at the initial try means that the current AT is not good
enough for whatever reasons
Thanks, Sergey
> -- 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
>> 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
