Tip: Handling invalid connections

On December 5th, Facebook will start enforcing their new token expiration policy and deprecation of "offline_access" scope. Therefore, I thought I'd preemptively answer questions around this by giving some insight on how to deal with invalid connections/tokens, both today and in upcoming versions of Spring Social.

Connections can become invalid for a number of reasons. Token expiration is one such scenario. But also a user could explicitly revoke access to your application, rendering the connection invalid. Ideally, if a connection is invalid because its token has expired, you could renew the connection exchanging a refresh token. But that's only for OAuth 2 providers and even then, Facebook doesn't support refresh tokens per the OAuth 2 specification.

Given that connections can become invalid for reasons other than token expiration, this is a problem to be dealt with even if Facebook had not deprecated "offline_access".

Whether a connection's token has expired or been revoked, the same strategy can be used to handle it. For that matter, lack of a connection can also be handled the same way. If a connection is determined to be missing or invalid (as indicated by an attempt to use it in one of Spring Social's API bindings and having a NotAuthorizedException thrown), the only real course of action that can be consistently applied across all providers is to remove the existing-but-invalid connection and then redirect the user through the authorization flow to establish a fresh connection. This can be done with a try/catch block explicitly on each API call or, better yet, in an aspect or servlet filter to be applied across all API calls in your application.

In fact, this is exactly what I have in mind with regard to https://jira.springsource.org/browse/SOCIAL-328. I'm already well on my way to having this implemented and hope to have it in a snapshot soon and part of Spring Social 1.1.0.M1 in the next few weeks. My goal is to make connection renewal as seamless as possible by automatically handling NotAuthorizedException, walking the user through the authorization flow to establish a new connection, and then (if possible) pick up where they left off in the application by attempting the failed operation again with the new connection.

You can help by keeping an eye on SOCIAL-328 and (when this ends up in a snapshot release) testing the automatic token renewal feature and providing feedback.