Web App: Juvely

Hi everyone!

Appologies for not posting recently, but James and I have been working hard on Juvely at getting the second section designed. At the moment we have near enough got all of the XHTML and CSS done, so we are nearly ready to start coding! We have now both finished university for the easter, so from now on we are going to be working harder than ever!

Anyway, onto the OpenID stuff. Hopefully most of you have heard of OpenID and know what it is about, I didn’t fully understand it until last week when I thought I had better see what all the fuss is about and looked into it. Over the past few days I have been thinking about how it could be integrated into Juvely and yesterday made a mock up demo of a account system that uses OpenIDs.

An explanation

If you don’t know what OpenID is or fully understand them here is a quick (ok, rather long winded) explanation. At the moment for each forum, application, whatever, you want to access that has some sort of account you usually need to enter a username and password, to tell the system that you are you. The main problems with this are you need to remember which username and password you used for each system. Most people usually use the same, which is bad because if somebody finds it out for one system they will have it for the rest.

Bring in OpenID, this intends to replace the username and password with just your ID. This can either be unique to you, or shared among many people. You may have one or you may have many, it doesn’t matter. The most common form of OpenIDs at the moment is as a URL, i.e. http://me.myopenidprovider.com/. So how are you authenticated then, well this is the clever
bit. On the system you want to access it asks you for just your OpenID. No passwords or anything complicated. When
you click the login button the system then sends a request to your OpenID provider asking it to verify who you are.
Once it has done this the OpenID
provider tells the system that you are really you and it lets you login.

The advantages of this are that it is decentralised, anyone can set themselves up as an OpenID provider and anyone can integrate their application into it. Most OpenID providers usually authenticate you by using a password, but as technology progresses we may get to a stage where we can use biometrics (or other ‘unhackable’ things) for authentication. For more information have a look at the OpenID website.

Edit: OpenID does not provide any authentication by itself, it just provides a way for systems to verify who you say you are.

So what does all this mean for users? Well if they come across this new app they like when they click the signup button they will have to choose a new username and password, and then enter all the boring old stuff such as email, language, etc. OpenID solves the problem of having to choose a new username
and password, and an extension goes even further by allowing details such as your name
and email address to be shared with an application. This can also help gain more users if you support OpenID as new users don’t get scared by that big signup form.

Implementation

Now I have told you why it is so good lets get onto implementation best practices and my demo. The demo was originally aimed just so that I could learn how to use OpenID,
but I have put it up on the web, just in case anyone is interested in seeing how it works. I made my demo using good ol’ CakePHP and followed this guide which provides a component to allow you to easily integrate OpenID into your app. My demo works like this:

1. User enters their OpenID and this is verified against their OpenID provider.
2. Their OpenID is checked against the database to find whether they already have an account, if they are now logged in.
3. If they don’t have an account they are shown whatever information we got from the OpenID provider and they can remove what they don’t want (if implementing OpenID into your app rather than just showing them it you should provide a way for them to correct incorrect information).
4. A new account for them is created and they a logged in.

On some OpenID documentation it said that you should allow users to associate many OpenIDs with one account, and if you provide user/password authentication to allow them to associate OpenIDs with an old account. The easiest way I would imagine to to do is have an old account table as so:

Accounts (id, username, hashed_password, …)

And then a table that holds OpenIDs with the Account id as a foreign key:

Openids (openid, account_id)

With this an OpenID can be associated to only one account, which depending on the way your app works and how you plan on using OpenID may or may not be a problem. They can also ‘upgrade’ their old account to use an OpenID for login.

The next problem I found was that all of these could refer to the same OpenID, so how do you tell them apart when storing them in the database.

http://me.myopenidprovider.com/, https://me.myopenidprovider.com/, http://me.myopenidprovider.com, me.myopenidprovider.com

With my CakePHP implementation once the user has been succesfully authenticated you can get it by using the following. I was a bit unsure about this at first because the OpenID provider responds with the OpenID as an argument which may not be the same as the one requested to be verfied, but I have dug through the code and I think this provides the correct one.

$openid = $response->endpoint->identity_url;

Mmmm k, that is all the useful info I can remember for now, but I will add some more later if it occurs to me.

My demo

My demo isn’t anything fancy, all it does is allow you to aggregate all your OpenIDs and keep track of your personal information (just in case you lose it?). I feel it is a good working example of how to use OpenIDs instead of usernames and passwords and the best practices of it.

Anyway, you can access it here and if you have any questions or comments just ask. There isn’t any secret code inside so if you have a great idea and want to use my code as a base give me a shout and i’ll upload it.

Well, that was rather long. Any questions, as always just ask. I think it is time I got back to work on Juvely now…