shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From A Clarke <>
Subject Re: Expected behavior when OAuth2 access token expires and no refresh token was given
Date Tue, 17 Jan 2012 21:03:38 GMT

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

OAuth2Request returns the approval url

Result is returned

Server requests the current access token be deleted and tries again with

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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message