Single Sign On Authentication Using a Symfony Framework

Friction Diagram

Friction. Good to have between tires and the road when you’re braking on a rainy night. Bad to have between you and the significant other when discussing buying a pool table or coffee table for the family room.

And more and more websites and web apps are coming to understand that friction between them and their users is a bad thing. If you surveyed users about “friction” they likely wouldn’t know what you even meant. But if you asked about some specific scenarios they certainly would have an opinion:

  • Would they rather have shopping cart items automatically removed or remain when they stop online shopping before check out?
  • When filling out a contact form via smartphone would they prefer the form require only minimum contact info or also include additional required fields?
  • When they land on a blog article should the requisite “Receive Our Newsletter” pop up appear right away or only after they’ve scrolled down a bit?

As with many things in life, the absence of friction isn’t something that usually registers with users, but they’ll definitely notice obstacles or challenges when using a site. And with average site session duration being just a hair over 3 minutes* you don’t want users to bounce away prior to getting what they want from your site.

The great Google in the cyber sky is a master at avoiding friction. Users sign in to a gmail account and they can flow seamlessly over to their Google Drive docs, YouTube channel and Google+ profile.

Implementing such a Single Sign-On (SSO) set up was probably no big deal for that tech giant. The rest of us might decide to employ Open Authorization (OAuth) for SSO. OAuth pemits a user to avoid creating a new account on a website but instead access it via their credentials from another site (e.g., their Facebook account).

Symfony Logo

SSO, Drupal, Magento, Symfony and a CMS of Your Choosing

A recent project presented us with a slight SSO variation. A client had a social networking site using Drupal, as well as a separate E-commerce site using Magento, and they desired SSO between the two. A further wrinkle was the possibility of adding a third site later on with another CMS (e.g., WordPress or an emerging one like ProcessWire). Similar to a Google, the goal was to eliminate any potential friction of their users having to sign in more than once.

The main solutions that were considered:

  • Directly connecting the Drupal and Magento sites via a custom Application Programming Interface (API)
  • Employing an OAuth solution
  • Wrapping Drupal and Magento in the Symfony framework to handle the sign on for both sites (plus any later added sites)

Among the reasons for not directly connecting the Drupal and Magento sites was separation of concerns. As more systems (new or legacy) are added to the overall architecture, each system would have to be aware of all others to maintain SSO. This quickly becomes unmaintainable as more systems are added.

The use of OAuth was ruled out because it is more for authorizing resources (e.g., does a particular user have permission or authority on a site). Our client’s situation only required the authentication of users (e.g., verifying the identity of a user). Additionally, OAuth necessitates the set up of an authorization server, which ends up being just another resource to be maintained.

Wrapping the other systems in a PHP framework to handle authentication for multiple sites became the obvious choice. We employed Symfony but others such as Yii would have also worked.  At a basic conceptual level, using Symfony obviated necessity of having the Drupal and Magento sites interact (as well as allowing for a simple “plug in” of a different CMS site in the future).

Beyond that, Symfony’s customizability allows for much greater flexibility than Drupal or Magento. That in turn allows for new features that must be present in all systems to be implemented in Symfony.

Single Sign-On Diagram (cropped)

A Sign of the Times & Those to Come

As users become more accustomed to a lack of friction the more they will expect it from the moment they land on a page, to every click (or lack of one) subsequently. There was a time when it was said, “As General Motors goes, so goes the nation”. Currently the same might be said of Google and cyber space.

Their use of single sign on will probably become standard and expected by users as they navigate around the web and among an entity’s various sites. OAuth might be the solution for some sites while custom solutions (such as the Symfony example above) for others. What is important is to keep the user friction free and making that happen smoothly behind the scenes as well.

*For the week of 9/21/14, average session duration was 3.10 minutes according to FireClick.

Endertech is a Los Angeles Software Development Company able to build custom database development solutions. Contact us for your free consultation.

EnderTechies Whiteboard Planning

- Endertech Alumnus | 

Filed under: <Development>