So, a bit behind on this which I’d hoped to have done last Wednesday, but head colds and real life wait for no one, particularly people who do development on their own time.  This pushes me up against my weekend deadline, but I have the old code to rely on, and, frankly, a little time pressure is a great way to get work done, eh?

A bit of research uncovers that while Google uses OAuth, it’s often limited to which service that you’re trying to access.  A bit more research shows that they also support OpenID, and in a way that meshes with their OAuth.  So, while I thought I’d be doing OAuth today, instead we’re going to work on OpenID.

The “Auth” in OAuth is actually more Authorize than Authenticate. For the boards app, I’m more concerned with Authenticate.  OpenID is only an Authentication method.  It does have a way to get some basic details about a person — a nickname, possibly an email, a few other tidbits, mainly about identity and the way people want to be seen.  There might even be a user icon, depending on the service.  That may matter more when we’re into Tokens, but it’s good to note now.

The same person who wrote the OAuth component for Cake also wrote one for OpenID.  OpenID is a bit more complicated than OAuth (for all that OAuth is perhaps a bit more secure, and supports doing more than just confirming identity.)  A good portion of this is that OpenID has had a chance to evolve, and can be (and has been) implemented by a lot of different people.  There’s signed and unsigned requests, two different ways to request information about the user (like their email or name), and within one of those ways there are multiple ways to make the request.  Typically only one of these ways is supported (if any are — and they aren’t required) so getting information back is tricky and not completely certain.

The only information you can really count on is a field called identity_url, which sits at the base understanding of what an OpenID is.  Basically, an OpenID is a URI which identifies a single person.  It’s like an email address in that way, really, and in fact, Google’s OpenID is based around your GMail account (or Google Apps mailing address).  It still returns a valid http URI, which uniquely identifes a user, and that’s good enough for us.

Using the cakebaker OpenID sample, I’ve got a method to allow for someone to enter their OpenID URL (which might not be the same as their identity_url), and log in using that information.  For Google, we already know the endpoint url, we’re using, and it builds the users’ identity_url for us, once that user logs in and agrees to our information request.  For now, we’re storing that url with the key ‘openid’ (just as for Twitter OAuth, we’re using ‘twitter’ and their user id that we got back from Twitter).

I again filled this in with my information and codes, and I’m logging in with Google.  The next piece will be what to do when someone who we don’t find in our database tries to log in.  We’ll want them to set up a new account, and for that we’ll want to grab a little bit of information from the auhentication provider, if we can.  That could be a username/nickname or an email,  and hopefully, a profile picture (which will allow us to set up a user token for the new person).   And we’ll need a way for them to modify this information, or provide the parts we don’t have so we can set things up.