Adding OpenID is easier than you think

2007 June 28
by mike

keys

I just got finished adding OpenID to my sideline application. Truth be told, I’d been putting this off for a month or so because I figured that it would be a real pain. But after a couple of hours I was pretty much complete and at the point where I started to goldplate.

The first step was to install the RESTful OpenID Authentication plugin. For Piston users, that’s as simple as typing the following:

CODE:
  1. piston import http://svn.eastmedia.com/svn/bantay/plugins/trunk/restfulopenidauthentication vendor/plugins/restfulopenidauthentication

For non-Piston folks (why aren’t you using Piston?), just install the plugin like normal:

CODE:
  1. ./script/plugin install http://svn.eastmedia.com/svn/bantay/plugins/trunk/restfulopenid_authentication

Once you’ve got that installed, all you need to do is run the generator and add a few routes to your routes.rb. Give the README a quick glance to get the detail for these steps.

One of the first things that I noticed about the generated code is that it’s definitely designed for a site that uses its own authentication system in addition to OpenID. Since all I want to do is use OpenID, I started getting rid of all the extra code.

That’s when I remembered the RESTful part of the plugin’s name and wondered “how do they do an authentication when the app’s API is called via XML?”. That is, what happens if there isn’t a nice login screen that will redirect to an OpenID provider and supply me with a lightweight authentication? The answer, of course, is obvious: I have to roll my own authentication. That means that all the code that I just removed will be needed again if I want to authenticate non-HTML requests.

While I don’t like the idea of a dual-authentication system, it seems pretty common out there. For example, Google authenticates your requests with an API key even though you already have a username and password with them. I suppose that what I’ll end up doing is have existing users register for a username/password if they want API access. That means that most users will only ever need the OpenID authentication and the username/password will be reserved strictly for the API.

If you haven’t tried OpenID (or created your own account), I highly recommend that you do it. And I’m not alone – 37 Signals just put up a special page to explain why OpenID is a good thing. Check it out!

I’ll post some follow-up info on the goldplating that I did to customize the forms and take advantage of something called the Simple Registration Extension.

[Post to Twitter]  [Post to Plurk]  [Post to Yahoo Buzz]  [Post to Delicious]  [Post to Digg]  [Post to Ping.fm]  [Post to Reddit]  [Post to StumbleUpon] 

3 Responses
  1. 2007 June 28

    You may also want to check out this article:

    http://www.theserverside.com/tt/articles/article.tss?l=OpenID

    The article covers the basics of OpenID with sequence diagrams, technical details of the communication between the two servers and finishes with an OpenID4Java library implementation example.

  2. 2007 July 5
    mike permalink

    @justen - Thanks for the comment and the link. I'll be sure to check it out. Have you used OpenID in any of your projects?

  3. 2007 July 5

    Sort of :)...

    I am the project lead for Atlassian's Crowd where we have recently added OpenID support.

    Within the enterprise, we have been working with the Liferay team to ensure compatibility.

Comments are closed.