Tag Archives: Single Sign On

Integrate Web Applications Vs Integrated Authentication

I’ve been trying to integrate web applications for a while now on ivany.org. Basically, I have WordPress and Gallery “integrated” into one site where it’s relatively seamless for the user. It works OK for the most part but I’ve come to the realization that I don’t really want integrated applications. What I want is integrated user control and authentication.

Why does every single web application have to have it’s own userid/password/access management? Why can’t they all just share some common thing? I think there are a couple different ways to achieve this. The first one is to use something common like a user’s email address. Instead of getting the user to create a “username” or “login name”, just use their email address. It’s pretty much guaranteed to be unique unless you have two users sharing the same email but then just tell them to go get a GMail or Yahoo account.

GMail. Yahoo. That raises the second question. Why should my web applications have to manage authentication of a user? Google and Yahoo both have web APIs (Google Account Authentication and Yahoo Browser-Based Autentication) now that allow you to authenticate a user through their system, as long as they have a Yahoo or Google account. This is fantastic. No longer would you have to manage user passwords because you would just off load that work to Google or Yahoo. Yes, there are some security concerns since you are trusting Google and Yahoo for controlling who authenticates on your web application. I think that’s relatively low on the meter though as both Google and Yahoo have a reputation to protect. They are going to work to ensure their system is secure.

So, instead of WordPress and Gallery maintaining their own user names, why not just let me add a user by their email address. Then I just control access, and other options on an email address instead. If I pull Google and Yahoo into the mix, I can allow access based on if I add a person’s email into the correct access control lists, etc. Easy. No messing around with setting up accounts in WordPress just to give access to an album in the Gallery for specific people. Once they authenticate, through Google or Yahoo, they have access to both web applications automagically. Heck, if they’ve already logged into their GMail account, they wouldn’t even have to log in to the website since Google would already know they were authenticated. This gives us the concept of single sign on. You sign on once to Google and all Google registered applications you go to after that in your browser session know who you are.

OK, and what about the other stuff that isn’t associated with an email address. On WordPress, there are other things associated with a user id. Stuff like your full name, IM contact info and other blurbs of information. This could also be pushed out of your web application since much of it is common. This is where OpenID and the Simple Registration Extension could come into play. OpenID is a decentralized identity system. With the Simple Registration Extension, it allows storing of typical stuff you would need when registering for a site. For what I mention above, you’d probably need a “not quite so simple” registration extension. ;)

And where is all of this going? No where. Until someone steps up to the plate and puts together all of the pieces to achieve this. Am I the person? No, not likely. It needs to be done by the major players in the web application space. If WordPress and Gallery (just to name a couple) were to move to a system like this, other applications may follow and new applications may use this model as the “standard”.

Is this a perfect concept? Heck no. There are probably numerous issues associated with moving all of your authentication and user information out of your application. It may even be more difficult to create such an application versus managing everything yourself in your own database. You would still have to at least maintain a database of users (email addresses) and what access or permissions they have for your particular application. Of course, what happens if you can’t reach Google, Yahoo or the OpenID server to try and figure out if the user who is trying to log in is actually who they claim to be? How do you handle users that don’t have a Google or Yahoo email account?

I guess I will keep hoping that something like this happens.