Adventures In Authentication

A Capital Region Drupal meetup (the first of its kind I believe) is scheduled for March 6th and I hope to be able to talk about authentication and identity. Just a couple of years ago the issue of authentication and identity on Drupal sites was limited to the functions of the Drupal login system. I remember that the first module I ever utilized to improve the login process was LoginToboggan. LoginToboggan adds such nifty features as logging in with name or email address, placing a login form on pages not accessible to anonymous users and much more. It's a great module and I still use it today. Since then we've also seen a few social networks like Twitter and Facebook increase greatly in popularity. So while millions of people create accounts on those services they may not necessarily want to create an account (and have to remember another password) on your Drupal powered site.

Lucky for us Drupal site builders that the big social networking players realized that in order to get even bigger they would need to reach out to other sites. They have done so via APIs such as Facebook Connect, the Twitter API and Google Friend Connect. All three of these services allow someone to login to a website with their credentials from each of these services. So this allows people to log in to your Drupal site with their identity from Facebook, Google, or Twitter. Pretty cool, eh? All you need are the modules that make the connection between your site and these services.

Modules do exist for each of the three services mentioned above. Facebook Connect, Twitter, and Google Friend Connect all allow you to authenticate users to your site. They require varying degrees of technical expertise to set up and the exact functionality varies too. The good part is that they all seem to excel at verifying the identity of an anonymous visitor to your site, at least temporarily. The bad part is that they really don't fit in with the normal Drupal account creation process. If you're just looking for someone to be able to authenticate temporarily to add a comment they work great. If you want someone to be able to quickly create a full account, with access to all of the features of your site, with Google, Facebook or Twitter credentials then the modules fall short. What seems to work best is a hybrid approach where a user first creates an account on your site and then later connects to their account on the social network. After that they can log in with one of these services (provided you add the right links) and get all the benefits of a member of your site.

Earlier I mentioned varying degrees of functionality. Besides authenticating users these modules can do some publishing back to social networks as well. Facebook Connect will publish a link to a comment to an authenticated user's wall on Facebook. It will not publish to the wall when a new node is created though. The Twitter module will post to the wall when you add a new node but not when you add a new comment. The Google Friend Connect module will publish and update a site's "social bar" when you add a node or comment but it's not clear to me where else this activity shows up. What would be nice, and what I hope to see at some point would be for each of these modules to have similar functionality where users could choose to share a variety of activity on the site they logged in with.

The issue of account creation is also an important one. In order for these modules to be very useful they really need to fit in well with the standard Drupal account creation process. At this time they do not. One possibility would be to be able to assign people authenticating via a social service a certain type of limited role while capturing the minimum amount of information (such as username and email address) to create an account. Then generate an email that invites the person to return to the site and fill out a full profile.

One other issue worth noting with the modules mentioned involves the placement of login buttons. Both the Twitter and Facebook modules add a button to the page at /user/login and to the login block. The Friend Connect button adds a button just above the comments but nowhere else. You can also use a snippet of code to place the Facebook and Twitter buttons where you want although the code isn't specifically made available. I just grabbed a snippet after viewing the page source html. I have been unable to do the same thing with the Google Friend Connect button. Examples of login placement are shown below.

Facebook and Twitter Login

Google Friend Connect Login

As you can see there are various differences and shortcomings with these three modules. In order to really have a positive impact on site membership I think they need to be more flexible (placement of the login buttons for example), more integrated with the Drupal account creation system from the start and have consistent publishing functionality. There are other options available if you want something that is "plug and play."

If you just want to authenticate for comments and offer cross-publishing you can add the Disqus module which utilizes the service of the same name to manage commenting. In order to use this you need to turn off Drupal comments and you also lose the capability to search comments. Also keep in mind that Disqus does not create accounts on your site either. For account creation there is the Gigya Socialize module which integrates with the Gigya service. I have tested the Gigya module a little bit but I'm a bit concerned about running user data through the servers of another party besides my site and the one that the user is authenticating from. If Gigya goes down or has performance issues then it could prevent logging in or registering on my site. The same things goes for the Disqus service. There's also the issue of terms of service. I noticed the following in Gigya's terms of service for the socialize module in section 3, paragraph b.

End User Content. You retain all rights in your End User Content. However, by uploading, posting, submitting, linking to or otherwise transmitting any End User Content on or via the Site or Service, you hereby grant to Gigya a non-exclusive, worldwide, royalty-free, sublicensable, perpetual and irrevocable right and license to use, reproduce, modify, distribute, prepare derivative works of, display, publish, perform, transmit and access your End User Content in connection with the Service and Gigya’s (and its successors) business including, without limitation, for promotion and redistributing part or all of the Service (and derivative works thereof), in any media formats and through any media channels.

I'm not completely comfortable with those terms. Gigya is well within their rights to set those terms since they are offering up free technology and computing power. As a site builder I would prefer to not expose myself or my community members to the possibility that their content could be published elsewhere. You might feel differently and in that case Gigya's service might work pretty well for you.

I think that it's important to discuss and ultimately create solutions for the issues discussed in this post. In fact I recently posted a bounty on drupal.org for a unified social authentication module. The bounty offer still stands. I'm also open to funding bounties for improvements to the individual modules as I have offered on in the Google Friend Connect issue queue. There are other discussions about this that I am aware of. The discussion called Social networking accounts: unified approach to store in external account data in user content profiles? covers some of the same issues I mention here and even mentions the fact that there is no module for LinkedIn. That's where I first say the Post It Everywhere module which is geared towards making authenticated cross posting easier. This module doesn't handle the sign up though. So there's still fragmentation.

All of this is a lot to digest. And I think it's too much to ask for one solution that does everything. After all, the meaning of everything changes as new social services and new functionality appears. It's an important discussion that I hope will lead to some better functionality soon. I'm going to do my part by talking about it, exchanging ideas and perhaps devoting some funds to help developers bring the features closer to what I would like to see.

Original Article:

Adventures In Authentication