Expected behavior when OAuth2 access token expires and no refresh token was given

[Michael Matthews <ma...@oclc.org>]

Hello,

I'm testing our OAuth2 consumer implementation with Shindig's
oauth2_google.xml gadget. Google is sending an access token (and no refresh
token) and everything works until that access token expires. When that
access token expires, what is the expected behavior?

Should Shindig attempt to request a new access token? I suspect updating the
query used in our OAuth2Persister implementation to only return non-expired
tokens would fix the issue for expired access tokens.  However, that same
API call on OAuth2Persister is used to return refresh tokens and I'm not
sure what effect this would have on Shindig's refresh token flow.

Should the gadget detect the HTTP 401 returned by the authorization server
and display the OAuth2 popup dialog that redirects the user to the OAuth2
provider's authorization endpoint?  The one issue I see with doing this is
that the JSON response from Shindig has an empty oauthApprovalUrl property
which would prevent the gadget from sending the user to the authorization
URL to get a new token.  If the authorization server sends back a HTTP 401,
should the oauthApprovalUrl be assigned so that the gadget can forward the
user to the provider¹s authorization endpoint?

Thanks
Mike

Re: Expected behavior when OAuth2 access token expires and no refresh token was given

[A Clarke <cl...@gmail.com>]

Mike,

The intended behavior on a OAuth2Request is to never return a 40X to the
gadget and should be independent of the persister queries you describe.
(One area I'm still a little fuzzy on myself.)

A = Access Token
R = Referesh Token

+ = in persistence and valid, not-expired
- = does not exist in persistence
E = expired or for some other reason invalid (like revoked on the resource
server)

A-
R-
OAuth2Request returns the approval url

A+
R+
Result is returned

AE
R+
Server requests the current access token be deleted and tries again with
A-/R+

A-
R+
Server requests a token refresh and hopefully gets into the A+/R+ state
again

A-
RE
This is where I'm not confident of how the server should (or does)
respond.  My thought here is that the refresh token should be deleted from
persistence and we go back to the A-/R- state.









On Tue, Jan 17, 2012 at 3:18 PM, Michael Matthews <ma...@oclc.org> wrote:

> Hello,
>
> I'm testing our OAuth2 consumer implementation with Shindig's
> oauth2_google.xml gadget. Google is sending an access token (and no refresh
> token) and everything works until that access token expires. When that
> access token expires, what is the expected behavior?
>
> Should Shindig attempt to request a new access token? I suspect updating
> the
> query used in our OAuth2Persister implementation to only return non-expired
> tokens would fix the issue for expired access tokens.  However, that same
> API call on OAuth2Persister is used to return refresh tokens and I'm not
> sure what effect this would have on Shindig's refresh token flow.
>
> Should the gadget detect the HTTP 401 returned by the authorization server
> and display the OAuth2 popup dialog that redirects the user to the OAuth2
> provider's authorization endpoint?  The one issue I see with doing this is
> that the JSON response from Shindig has an empty oauthApprovalUrl property
> which would prevent the gadget from sending the user to the authorization
> URL to get a new token.  If the authorization server sends back a HTTP 401,
> should the oauthApprovalUrl be assigned so that the gadget can forward the
> user to the provider¹s authorization endpoint?
>
> Thanks
> Mike
>