eCommerce platforms can gain and provide significant value by connecting with their users on social networks. These networks are a treasure trove of valuable data about users and their friends, and can allow websites to fit more naturally into their users’ lives. According to a study by Edison Research in 2012, approximately 56% of Americans have a profile on at least one social networking site, and on any given day 48% of users log in to the website. Simply by connecting to your customers’ existing profiles, you can gain access to huge amounts of data about them and their—on average—130 friends that can help you to more accurately target marketing to your users. And since that is where they are spending the majority of their time online, it will enable you to connect with them where they feel most comfortable.
Additionally, allowing for social sign in on your website can help to remedy one of the largest sources of lost revenue for ecommerce websites: cart abandonment. According to research from Blue Research, 92% of users have abandoned a website after forgetting their login information, and a third of users say they do this “frequently.” Users today are subject to registration fatigue. They are not able to remember different usernames and passwords for each website they use, and become extremely frustrated to the point of canceling purchases they otherwise would have completed. In the same Blue Research study, 64% of users who frequently leave sites due to forgotten login information said that social logins would be helpful, and another study found that 40% of consumers would prefer social logins over creating a new or guest account.
OAUTH
Since the specification was first released in 2007, OAuth has been the standard method of authentication for software-as-a-service providers. OAuth provides the means for a client website to access user information from a third party on behalf of the user, without requiring the user to provide their login details. Unfortunately for developers, implementing the OAuth handshake with various providers can be quite tedious. There are currently two major OAuth specifications, versions 1.0 and 2.0, the newer of which is not backward compatible. Additionally, the specification leaves several important implementation details up to the service provider. Editor Eran Hammer famously left the working group for OAuth 2.0 because of the indecisiveness of the group toward the protocol. The OAuth 2.0 Authorization Framework document itself even contains a section that states, “…this specification is likely to produce a wide range of non-interoperable implementations.” All of this results in a standard that isn’t so standard across all of the providers that use it.
The fine folks over at Spring realized what a hassle managing these connections was and developed Spring Social, a project that drastically simplifies the process of creating and managing third party provider connections. The goals of the project are to abstract the specific implementation details of each service to provide developers with a simple method of getting each service’s API in a strongly-typed Java binding, and to cleanly organize stored connections so that they can be associated with the application’s local users.
To provide the above functionality, Spring Social relies on four main components: The connect framework, provider-specific modules, the connect controller, and the sign in controller. I’ve created an example project to show you how this works, which you can download below.
THE CONNECT FRAMEWORK
The connect framework is the meat and bones of the Spring Social framework. First, it defines the Connection<A> interface, which represents each connection to a provider. Since each provider-specific API is different, the connection interface creates a common API to model each connection. It requires connection implementations to include basic information about the connection, such as the display name and profile URL of the user, as well as methods to test and refresh the connection and to access the provider-specific API. This interface allows developers to write more generic classes that can be used with all providers. In the example project, AccountConnectionSignUp and SocialSignInAdapter both utilize the connection API to access users’ information without special logic for each provider. This enables developers to easily add or remove provider modules without refactoring connection management code.
Next, the connect framework defines a ConnectionFactory for each of the supported authorization methods. Currently they are the OAuth1ConnectionFactory<A> and OAuth2ConnectionFactory<A> interfaces. Each provider extends one of these factories, defining the individual protocol that it uses. If you were to search within the example project, you would not find any mention of any authorization method. Since all of the details as to how the connections are implemented are abstracted into one of these interfaces, providers can easily swap out connection factories or implement new ones whenever OAuth standards change or a newer approach arises.
PROVIDER SPECIFIC MODULES
Each provider that Spring Social supports has its own module that contains all of the implementation details needed to connect to that provider. A full list can be found here. All of the modules are developed in a consistent manner, such that each one defines similar classes, which ultimately result in two exposed classes for developers to work with. These are the Java API for the service, titled as Provider (e.g. Twitter), and the provider’s connection factory, titled ProviderConnectionFactory (e.g. TwitterConnectionFactory).
The Provider API class is a strongly-typed Java API, that allows Java applications to directly consume the API. This is a huge benefit to Spring Social over simply implementing OAuth, because all of the individual HTTP/REST calls required to send or receive messages from the service and marshaling of returned objects are abstracted away. The Java Facebook API used in the welcome method of the HomeController from the example project allows us to perform what would regularly be several lines of HTTP requests, with callbacks and marshalers, in just a few lines. Provider APIs provide for a more consistent development experience, and allow the developer to stay focused on business logic rather than on implementation details.
Spring Social already has support for most major OAuth providers on the web, including Facebook, Google, Twitter, LinkedIn, and even more business-oriented services such as Salesforce and QuickBooks Online, but if you find a module that doesn’t exist, it’s incredibly easy to roll your own.
CONNECT CONTROLLER
The connect controller is a Spring MVC controller that defines connection URLs and handles the handoffs between site and service that happen during the OAuth handshake. This is the controller to use if you want to allow your users to simply connect to the third party service without having the ability to sign in through the third party service. The most important URL the connect controller registers is POST /connect/{providerId}. To make a connection for a logged in user, all you have to do is make a post request in the format above, where providerId is the id for the provider you want them to connect to. This format is completely extendable, and will support any ProviderConnectionFactory that you register in your project. Once the proper link is opened, the connect controller uses information from the request and the provider to automatically determine the proper authorization protocol to use (OAuth 1, 2, etc.) and completes the authorization. A similar URL also exists to delete the connection.
Connection factories can be registered using xml as seen in spring-social-context.xml. To add a new provider module, simply add the module’s ProviderConnectionFactory the the connectionFactories list.This will allow the ConnectionFactory to be automatically located using its providerId.
SIGN IN CONTROLLER
The sign in controller is very similar to the connect controller, except that it enables you to sign users in with their connections. Similar to the URL that the connect controller creates, the sign in controller registers POST /signin/{providerId}, and automatically handles the authorization, and then signs the user in. In home.jsp of the example project, you can see just how easy it is to initiate the sign in flow. The welcome page contains one button that posts a form to “/signin/facebook” with a hidden scope object that has permissions information as the value. Here we are requesting several permissions from Facebook, including email, user_likes, friends_likes, and publish_stream. These permissions will allow our app to get the user and the user’s friends’ like information as well as their email address, while providing our app with the ability to post to the user’s timeline. Facebook has several different permission values, while other providers only have one or two. After completing the OAuth dance, the sign in controller checks if the user already exists in the usersConnectionRepository, and either uses SocialSignInAdapter to log the user in, or AccountConnectionSignUp to register the user automatically.
WRAP UP
As you can see, there are numerous benefits to using Spring Social instead of plain OAuth. Spring Social handles all of the variants of the OAuth protocol that are out on the web, and with its support of provider specific modules, anyone can adapt it to connect to any OAuth enabled provider. The framework provides built in connection storage and management, and provides users with a Java-consumable API specifically tailored for the service they are using. In addition, though Spring Social currently relies on OAuth, it is not dependent on the protocol. Since authorization protocols are completely abstracted from any exposed connection details, no refactoring should be required when providers inevitably change their authorization strategy. While other developers will have to completely rewrite their authorization code, Spring Social developers will simply update the version of their provider modules.
Be sure to follow us on Twitter or LinkedIn for more great tips. Have a question related to Spring Social? Use the comments section below to join the conversation.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
