On 21/11/12 14:53, William Mills wrote:
401 not 400
Yes, thanks,our code does return 401 in the client to resource path failure case.
I wonder it would make sense to clarify it in the future revision somehow. I guess it is just HTTP at the stage of the client accessing the resource and may be no extra clarification is needed;
That said the only place where 401 is mentioned is the section I linked to below which says "MAY" while 400 is also mentioned at the the top of the section, where the section itself deals with errors to do with the client requesting an access token, while the 'client to resource' path is not covered.
Either way, thanks for the answers/help Sergey
------------------------------------------------------------------------ *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
