Yes, thank you. I should have said 4XX for what I really meant there --
"whatever the right authorization error code is". :)
-- Justin
On 11/21/2012 09:53 AM, William Mills wrote:
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 <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
