401 not 400

________________________________
 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
> 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

Reply via email to