Being an “experienced web applications user” (and developer), what is boring me most is that I have to subscribe/register in/to every new site I like to test or use. This gives me many login/password couples to remember and it is 1) dangerous (you keep using the same password for too many services), 2) boring and frustrating (“Oh no, yet another register form”)

The obvious solution is the use of a sort of Single Sign On: leave your user credentials somewhere (centrally) and give web applications the possibility to act as a client to retrieve them (via web services).

It’s the “register once, login everywhere” paradigm, baby.

The biggest problem, here, is a trusting one: WHO is about to store the credentials? Why should I trust a 3th party service to store the access key for so many services? The answer is simple: use someone who you ALREADY trust!

Here comes Yahoo!. It already has millions of registered, known users. Why not use its huge user base which can potentialy access your application?

Yesterday Yahoo! launched its simple SSO service: bbauth. As an web applications user, you can now use your Yahoo! user id to gain access to a bbauth-enabled web site. As an application developer, you can easy your ever standing “login/password” headeache and you can potentially vastly extend your user base with those lazy users that bounce over every registration form. That is: more user for your application.

In the application a “Login via your Yahoo! id” link will bring your user to a Yahoo! login page… then, s/he have to confirm his/her will to give your application LIMITED access his/her credentials (this is because, lately, your application COULD use his/her credentials to access their photo, or delicious bookmarks or every bbauth enabled yahoo web service). Then, the user is redirected to one page of your application as a logged in user (but now, with the token given by Yahoo!, you’re on your own).

On my own opinion, there are at least 2 major problem with this approach:

• the user have to read and accept some terms of condition for every application he use via its Yahoo! id, even if the application DOES NOT use his credentials, but use only the SSO service
• Phishing attacks…

Finally, the other SSO solutions. I know of them, but they were not so widely known, and only a widely adopted solution would worth the developer effort to include it in his application.

They are:

• The google one Why didn’t I know of it? Perhaps this is not only a problem of mine ;) And, btw, this is not the exact same service (but I have not investigate the details)
• OpenID it’s too.. geeky (imho), but read ahead

I’d like also to promote this concept: the importance of BBauth is great not only beacuse Yahoo! is so clever and smart (and web2.0ish)… not only because its userbase is yet HUGE… there is another point of view: people implementing bbauth on their site will then (yes, maybe) be tempted to also implement the OpenID solution (that is open, and that is an ethically GOOD THING when dealing with user data). So adopting bbauth we promote the very concept behind OpenID itself, and then we promote OpenID.

There have not to be ONE SSO solution. We all never like Microsoft Passport. There should be SOME (not MANY) sso solution, and everyone should choose wich he/her like more.

Anyway, yahoo or not, the path is now clear: if you’re about to write a web application, please give me these options:

       Hello, please register to XYZ.com, 
       or use your [yahoo!|google|openid|whatever] 
       account to sign in. Thank you!

There are yet some interesting implementations: visit them at its Yahoo! code gallery

We already have:

• A Drupal module (contains also some reusable php4/5 classes)
• A Ruby wrapper for bbauth
• A Rails plugin

Note: as for now, Yahoo! does not yet provide a way to access user name and email ot its users… only use her credentials for web services (none of them, afaik, can retrieve user data) after a sucesfull login.