Web 2.0 Single Sign-On
Duncan SampleAt a time when all new sites are 'web 2.0', AJAX, and more traditionally client-side applications are becoming web-based, why can't we standardise on a single sign-on procedure?
I have an account at almost every site I can think of, and since there are too many sites online to be able to create different passwords for each one, I tend to choose between a number of standard passwords that I use (depends on the level of security desired, etc). I also manage to get the same username on practically all the sites I sign upto. This makes it easy for me to sign into any site I know I have an account for. If I get the same username, use the same password, I sometimes think that I shouldn't actually have to register and that this information should be shared somehow between the sites.
After listening to some of the older episodes of 'Inside The Net' (a podcast hosted by Amber MacArthur and Leo Laporte) I noticed a comment about single sign-on, and people's attempts at making centralised systems. The first problem I can see with TypeKey and Passport/LiveID is that they're run by companies, companies that sell products, and therefore have a bias towards a platform/application/advertising/etc.
There are of course open source initiatives, Open Passport to name just one, which is taking the idea of the Microsoft Passport system and providing an open version. Others have created protocols, specifications, and libraries (eg. OpenID). These protocols, I'm sure, have all sort of security write-ups, case studies and documentation, but we need a simple implementation. Let me explain...
The harder you make something, but less developers are able to implement it. The less people implement it, the less widespread and therefore less useful it becomes.
The second failing is that the single sign-on I've seen (the ones I've seen, at least), require you to go to the originating site to create an account, and usually even go through an interface in their site to login (TypeKey/Passport for example). This creates an image of a 'controlling site', where the users think the sites have some sort of governing body. Developers certainly don't want to appear like that either.
What we need is a simple web service that keeps username and password, and probably the email address of anyone, taken from any site that wants to use it. It needs to be done by a trusted party (who do people really trust though???). I'm thinking of a SOA Web Service that provides the following interfaces:
- Register(username, encrypted(password), verifypassword, email)
Register a new user. Errors: Invalid username, User already exists, incorrect password, invalid email - Login(username, encrypted(password))
Processes a login. Errors: incorrect
Something I really like is the way Flickr works with it's API. The developer registers for an API key, implements the API into their application/site, then when a user uses it for the first time, Flickr asks the user if they intentionally used their account through the application. This could be one route to go down for a 'registration successful email' when the user logs into an application/webapp for the first time.
Anyway. Enough of my slightly disjointed rant, any comments, pointers to simple web services which are already available and being used would be appreciated.
