The criteria that the library uses to determine the validity of access token is not good enough to cover few corner cases

[GoogleCodeExporter]

I was going through the source code and I was wondering if the 
following criterion[present within login(AuthRequest req, final 
Callback callback) method of Auth .java] is enough(does it cover all 
corner cases ??) to determine whether a previously-fetched access 
token is still valid or not  . 
 final TokenInfo info = getToken(req); 
   if (info == null || info.expires == null || expiringSoon(info)) { 
      doLogin(authUrl, callback); 
    } else { 
      scheduler.scheduleDeferred(new ScheduledCommand() { 
        @Override 
        public void execute() { 
         callback.onSuccess(info.accessToken); 
        } 
     }); 
  } 
The reason I ask that is because I am not sure if the aforementioned 
criterion covers for following case: 
1)User opens a brand new browser session. 
2)User  visits  TestWebsite.com(TestWebsite.com uses gwt-oauth2 to 
interface with facebook) 
3)User clicks on, say, the classic fLogin icon, present on 
TestWebsite.com and that user action results in the facebook login 
window to popup. 
4)User enters his/her facebook credentials into the pop up, clicks 
"log in" and logs in succesfully  to TestWebsite.com using facebook 
credentials. 
So far so good. 
5)Now, the user opens a different tab and visits facebook.com and logs 
out of facebook.com by clicking the log out link of facebook.com. 
6)The user now switches to the tab with Testwebsite.com and logs out 
of Testwebsite.com as well. 
7)The user, who is still on Testwebsite.com, clicks on the fLogin 
icon. 
Now, it seems like gwt-oauth2 is still trying to make use of the 
previously fetched access token which is no longer valid because of 
the fact that the user has logged out of 
facebook.com 

Original issue reported on code.google.com by karthik....@gmail.com on 8 Jun 2011 at 3:49

[GoogleCodeExporter]

I'm not sure that signing out in another window would necessarily revoke the 
access token granted to the application -- applications should continue to have 
access even if the user logs out, at least until the token expires. Are you 
finding that not to be the case?

But, you bring up a good -- though unrelated -- point. There is no way for an 
application to know that the token has been *revoked*, for example by visiting 
https://www.google.com/accounts/b/0/IssuedAuthSubTokens and revoking access to 
an application. I believe Facebook has a similar page.

So storing the token may result in using a token that's been revoked elsewhere, 
which will only present itself when a request is made with that token, and the 
response will be an authorization 4XX error.

Unfortunately the protocol doesn't provide any mechanism of getting notified 
that a token has been revoked, so the best we can do is either:

1.) Always check authorization status before making any request. This would 
require the library to be able to be configured to disable token storage (which 
is a good idea anyway, by the sounds of it), and would result in an 
auto-closing popup to be displayed before each request. That's...not a great 
experience.

2.) Don't pre-check authorization, but catch failed requests that fail because 
of a bad token, and automatically refresh the token and retry the request. This 
will require deeper integration with the requesting mechanism (JSONP in most 
cases), and in fact is planned to be supported for Google APIs as part of 
ongoing integration with the GALGWT project. This should be a better user 
experience, but requires a little more work on your/my part :) -- Luckily, this 
method also allows for tokens to be stored, so that a popup doesn't have to be 
opened on each request. It's win-win! :)

If you need more details, I'd be happy to help, I'm not familiar with any 
problem with tokens after the user logs out of the service provider, so more 
details there would be helpful.

Original comment by jasonhall@google.com on 8 Jun 2011 at 4:57

[GoogleCodeExporter]

I'm going to mark this as Invalid since it seems to be outside the scope of a 
pure OAuth 2.0 library. I've described some methods by which you can integrate 
your request mechanism with this library to do smarter things, which should fix 
the problem you describe.

Original comment by jasonhall@google.com on 21 Jul 2011 at 3:07

• Changed state: Invalid