On 27/11/12 08:52, Guangqing Deng wrote:
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?
I believe an access token response may offer an expires_in parameter
which can provide some hint. Actually this raises an interesting question.
Suppose the client actually checks this parameter and decides to use
a refresh token it also has to pro-actively refresh its current token.
IMHO this should work even if the access token has not expired yet and
effectively represents another form of a client-initiated revocation of
the access token ? It will mean a client which works with the
"expires_in" parameter can save a one round trip (the one which returns
a failure in case of the access token being expired) ?
Does it make sense ? If it does, can some relevant wording make it into
the revocation token draft ?
Cheers, Sergey
------------------------------------------------------------------------
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
