I've been burried in work on my experimental social media/entertainment site and a key part of any site like this is setting up user accounts. It's also invariably one of the more painful aspects of any site - it treads the fine line between low friction (not putting barriers in the way of potential users from joining) and having enough information to successfully identify and communicate with the user.

To try and make things as simple as possible, I've been looking at OpenID. The idea is to consolidate authentication. Instead of having to have yet another username/password kicking about, a central authority provides identification and authentication, and everyone else operates off that. Seems like a great idea, but it's got it's warts.

Security

The moment we start talking about any kind of authentication, we need to take into account security. Users are going to be using passwords and at that point a whole can of worms is opened. It means that SSL would be needed, we would be handling passwords which many users probably use on other sites and would need to treat them accordingly, plus it's just another account / password etc. for users to manage.

OpenID certainly helps - I no longer need to worry about anything other than storing basic account information and just pass the user to their preferred provider to authenticate. The one thing that always needs lot of thought (but in my experience in most companies, rarely gets it) is how much to trust a third party.

The moment I choose to use a system like OpenID, I'm trusting my site security to someone else, and my security will be no better than theirs. Worse yet, where you support many providers, each brings with it it's own set of risks. That's something to take seriously if you have any kind of sensitive data on your site.

That would rule out mechanisms like OpenID for anything where financial data, personal data or anything at all sensitive or of value was involved. Fortunately with a social site that's p entertainment, no sensitive data is involved - it's almost all read-only to the public anyway. The only reason why authentication is needed at all is to reduce the risk of unauthorised modification of a user generated content.

Happily, OpenID and similar are more than sufficient for that!

The nuts and bolts

The next step is to actually implement it. For portability and ease of initial development I'm using a standard LAMP stack. Not as efficient as some, but it's certainly capable of scaling (eg. Wikipedia uses LAMP embellished with other technologies to deliver it's huge scale) and not likely to go away any time soon which can often be a major problem with proprietary "flavour of the month" platforms.

The default OpenID library for PHP is php-openid, and that's where things start getting messy. The ideal for me is a class which I can hand off the whole authentication process and pretty much just gets back some form of response to the authentication being successful (or not) and some unique identifier for the user, and basic contact information (email).

Alas, it's not quite that simple. It turns out that there are different approaches taken by different providers. My initial implementation just used almost exactly example code and I spent hours trying to make it work with Google. As it turns out, Google uses AX (Attribute eXchange) instead of SReg (Simple Registration).... so I had to add support for that. Add to that that different information is available via AX and SReg for some stuff and we start gathering inconsistencies and exceptions in the code already. Worse, we start gathering in inconsistencies in user experience.

Then, different providers use different approaches to the OpenID URL. Some provide one universal URL for all users and some add in the username to the URL. That's just horrible! I now have an enforced inconsistent user experience. I fact I now have 3 different ways to pass users off for authentication.

Now as if that isn't enough, some potential providers have decided that they aren't going to support OpenID, but are instead going to provide their own authentication mechanism. So now I have to implement other authentication mechanisms all together.

The net result is instead of using some nice off-the-shelf class to provide me with universal authentication, I'm now having to glue together lots of bits in a wrapper class to abstract it all into a uniform authentication process for my site. That's a pain and providing a lot more work than should really be necessary.

User experience

The key thing I was aiming for was ultra-low friction for joining my site. That clearly has it's limits with the inconsistencies imposed by ID/authentication providers.

The thing that I think needs more thought here is if a standards like OpenID should also be specifying a user experience to make it universal across all providers. It would make it much more attractive for consumers (like myself), but would make it less attractive for providers who like to differentiate themselves in the market.

That's a conflict that will never go away - the best we can do for now is try and establish the best possible user experience up to the point that the user gets handed over to a third party for authentication.