Zilla Smash!

As some of you may have noticed I was really excited when Yahoo! released their BBAuth tool right before their Open HackDay (My post about BBAuth). It seemed like a great idea, as tons of people already have Y! accounts. Little did I know that BBAuth wasn’t really a good solution as a single sign-on utility. It sounds silly for me to say that especially when the Official BBAuth Site says “BBAuth also offers a Single Sign-On (SSO) facility so that existing Yahoo! users can use your services without having to complete yet another registration process.” In the real world when I implemented Y! BBAuth as a SSO provider I ran into some issues.

First though, a quick overview of how BBAuth works. You set up an entry in the BBAuth DB for whatever site/webapp you’re going to use it with, providing some general info like contact details and the endpoint for when a user has successfully logged-in. Once that’s done you get a shared secret and an application ID. These are used in all future calls to hash info so that it’s reasonably secure and can’t be easily snooped along the wire. A special login URL is crafted that points the user to Y!’s login page, and once they enter their Y! credentials they are asked to give permission to whatever site for the info that has been requested. Once they agree they are redirected back to the site along with some encrypted info depending on what the site had asked for.

BBAuth works just fine, but even if you don’t ask for any Y! info your users still have to go through and agree to allow the site to use their info. My problem is then that I don’t want the user’s info. When I set up my site to use BBAuth I even told Y! that I didn’t want to use any info. All I want is Yahoo!’s promise that the user is a real Y! user and some sort of unique hash that my system can use. I’ll get the info I need for whatever app I’m running at the time, but none of what I do would be asking for Y! Photos info. I’m not saving any login credentials via cookies or anything, I just want a simple login mechanism that I don’t have to maintain. Clicking through one page doesn’t sound so bad until you realize that every time the user logs in they have to go through it. That’s pretty annoying and makes the jump to a Y! login page even more jarring.

There’s a post on the ydn-auth group by Jeremy Zawodny (Jeremy’s Post) that addresses this issue and says that this functionality is apparently a special case for BBAuth. Seems a little odd but I suppose that they were more concentrated on the usage cases for sharing a user’s Y! info with a 3rd party site. So they know about it and are looking into it, but until then I can’t really say I’m pleased with the actual implementation of BBAuth as a SSO provider.

After implementing BBAuth and being disappointed with the SSO performance, I began looking into other solutions. I really didn’t want to require users to sign up for yet another account because everyone hates that. It seems like there’s been a lot of buzz lately around OpenID (Technorati stats for “OpenID”). I figured I should at least give it a shot considering the large surge of interest behind it. First I had to figure out how OpenID actually worked.

Short Version: instead of a login that is some clever play on your name (Tivac lol) or something you identify yourself using a URI that links back to an identity provider. The identity provider stores your details and provides password authentication, so that when you visit an OpenID-enabled site you enter in your identifying URI and get bumped to your identity provider. You log in there, specify what details the site should be able to see from your profile, and then say “Ok” and get sent back. Note that this is what it’s like using MyOpenID.com because I was too lazy to set up my own half-assed identity provider.

So, how does OpenID work as a SSO provider? From a user’s point of view it’s pretty dead-simple. Looking at it as a developer adding it to an existing property proved to be considerably more work than I expected. I used the JanRain OpenID Library for PHP when working to get OpenID logins enabled on my testing site. Now I know the title of the article doesn’t say I’m comparing the libraries I used for each, but it’s still interesting to look at the differing amounts of code required for BBAuth and OpenID implementation in a fairly typical hosting environment.

The first thing that struck me as kind of odd was that I needed to move two folders totaling 33 files onto my shared path. I had forgotten that OpenID uses Yadis (Wikipedia page linked because the homepage at yadis.org has been vandalized) as part of the protocol. I didn’t realize that I’d need to be installing classes to support Yadis as well as OpenID. Once I had gotten all those files copied into the proper places and confirmed they were on my shared path it was time to look at the examples provided.

OpenID provides a decent example setup for both consumer and server roles, where consumer is providing the SSO login and server is actually running your own identity server. I only want to run a consumer right now, so I used just those files. After getting the form setup and trying it out I discovered that my PHP install has no big integer math library installed. This necessitates running in “Dumb Mode” which according to the documentation means my login form is more susceptible to relay attacks. Great.

After defining a new constant telling OpenID to run in dumb mode I was able to be successfully bounced out to my Identity Provider, sign in, and be bounced back to my site.

Avoiding any in-depth analysis of the security between the two as I’m not qualified to comment, which did I prefer implementing and using? That’s not actually an easy question to answer. BBAuth was certainly much smaller in terms of code required. It also has the advantage of using Yahoo!’s login system, it’s not exactly scientific but I don’t know anyone who doesn’t have a Y! account. So BBAuth has a huge built-in userbase right there. Both services require bumping the user out to a 3rd party login page so that’s a draw. I knew it was part of how both worked going in and it isn’t an issue for me in this case. Implementing OpenID had some bumps but thanks to the distributed nature of the project I don’t need to go sign my web application up anywhere. If I want to shift around page names I don’t have to remember to go update any entries in a Y! database anywhere. Any OpenID Identity Provider worth their salt will also provide a mechanism to say “Always Allow this site” which is something that BBAuth currently lacks.

In the end I wasn’t able to come up with a conclusive win on either one. BBAuth has that annoying extra page every visit but tons of people have Y! accounts. Implementation was also pretty quick and easy. OpenID took more work but with a decent Identity Provider will only require one page not on my site. It’s also got the whole distributed thing going for it. As it stands now I’ve implemented both and users can just choose their favorite. I’d prefer to just offer one but I don’t think there is one that offers a compelling enough featureset over the other to go with a single one yet. Going with both gives me flexibility and an excuse to keep playing with both of them.