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