Interview with Spring Social Lead Craig Walls

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.