Following on from the recent release of Spring Social, InfoQ caught up with Craig Walls, lead of the project. The first question was what the driving force was behind creating Spring Social:
Craig Walls: There are a lot of places online where people maintain some facet of their identity. There are social networking sites such as Facebook and Twitter let people connect with friends and family to share tidbits of their life. But even services that aren't considered “social”, such as Dropbox, hold resources that are a piece of that person's online presence.
Many of these services expose a REST API so that applications can be created that interact with that information on behalf of their users in ways that go well beyond that service's core functionality. With over 750 million people on Facebook, over 200 million on Twitter, and a similarly large following on other services, it's clear that there's great opportunity to build applications that plug into a user's social and online experience.
Building such applications can be tricky, though. Consuming a REST API seems simple enough, but before you can do that you must obtain authorization to access the user's resources. And once you have authorization, you'll want to store that connection for long-term use so that you don't have to ask the user for permission to access their resources again. When you make the call to the service, there's the matter of binding the response to model objects and dealing with any errors that may occur.
Spring Social was created to simplify development of applications that connect with service providers by handling the connection process and offering Java bindings to the services' REST APIs.
InfoQ: What kinds of applications do you see will be integrating Spring Social connectors?
Craig Walls: Spring Social is a perfect fit for any application needing to interact with one or more service providers on behalf of its users. This may include simple integrations such as reading a user's Twitter stream or posting a photo to a user's Facebook wall.
But an application may also do something even more interesting to enhance the user's experience. For example, a music streaming application might use Spring Social to fetch a list of the musicians that a user has "liked" on Facebook and use that information to tailor the user's music playlist. That same music service might look at the user's TripIt itineraries and notify them of concerts or music events in the cities they're traveling to.
One of the things that makes working in this space so interesting is that there's no end to the creativity when it comes to utilizing the data that a user has authorized an application to access to improve their overall online experience.
InfoQ: Spring Social appears to be heavily intertwined with OAuth providers. Are there requirements that all Spring Social providers be OAuth based?
Craig Walls: Spring Social 1.0.0 includes direct support for connecting with providers that secure their users' resources with OAuth; whether it be OAuth 1.0, OAuth 1.0a, or OAuth 2. This covers a lot of ground, as the majority of service providers implement OAuth, including several well known providers: Twitter, Facebook, TripIt, GitHub, Foursquare, Gowalla, and many more.
That said, Spring Social's connect framework is extensible. Thus, Spring Social can be extended to support providers that use other authorization protocols.
InfoQ: What's the difference between OAuth 1.0 and OAuth 1.0a?
Craig Walls: OAuth 1.0 had a security hole that enabled an attacker to start the connection process to obtain a request token, then trick a victim into authorizing that request token, and finally complete the process granting the attacker access to the victim's resources. This hole was plugged with the OAuth 1.0a specification.
It's unfortunate that there are some providers that still employ OAuth 1.0. However, most of them have OAuth 2 on their roadmap to move away from OAuth 1.0 and in the meantime they are confident that the short lifespan of a request token (usually only a few minutes) makes it difficult to orchestrate such an attack. A few have implemented additional constraints in their OAuth 1.0 implementation (such as requiring that the callback URL matches a pre-registered callback URL) to mitigate the risk. Some have also taken steps to warn users to only agree to authorization if they recognize the application requesting access.
By supporting OAuth 1.0, Spring Social enables connectivity with those providers, including popular ones such as TripIt and Dropbox. It's still important to be aware of the issue when developing applications that connect to OAuth 1.0 providers.
InfoQ: The secret keys needed by Twitter (and others) ideally need to be stored in an encrypted form in a database. Is this supported in Spring Social?
Craig Walls: Absolutely! The access tokens and secrets granted to an application can be used to access a user's provider resources and thus should be kept away from prying eyes. Therefore, when configuring a Spring Social connection repository, you must specify an encryptor that the connection repository will use when persisting the tokens and secrets. The encryptor can be any implementation of Spring Security's TextEncryptor interface. In our sample applications we use a no-op text encryptor to keep things easy for someone learning Spring Social, but a stronger encryptor is recommended in production applications.
InfoQ: Finally, given the nature of OAuth and the three-legged browser-based authentication, do you think Spring Social exists mainly for web-based systems where there is a browser at the other end, or could it be used for headless systems?
Craig Walls: Spring Social 1.0.0 supports OAuth 1 and OAuth 2 flows where the user is involved. This includes what is commonly known as three-legged OAuth 1 and OAuth 2's Authorization Grant and Implicit Grant flows. These flows all involve the user's browser being redirected to the provider for authorization.
That doesn't necessarily mean that an application using Spring Social must be a web application. An Android application, for instance, is not a web application, but may use Spring Social to connect to a provider. In doing so, it would only need to use the Android device's web browser for purposes of authorization, but the rest of the application may be completely native.
For headless applications, other authorization schemes where the user isn't involved, such as 2-legged OAuth 1 (also known as "signed fetch") or OAuth 2's Resource Owner Password Credentials or Client Credentials schemes would be used. Spring Social does not support these schemes in its 1.0.0 release, but we are looking into them for a future release.
You can find out more information from the Spring Social home page, which includes a list of the additional connectors available. Although the 1.0 release included a Facebook and Twitter connector, several other connectors are in development (such as GitHub, TripIt, Linked In) as well as other community driven connectors such as Foursquare and Instagram. If you have any further questions on Spring Social, please leave them in the comments below.