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

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.

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.