Why the lack of OpenID-enabled Rails apps?

OpenID has been quickly gaining momentum this year, with Microsoft’s future role as an identity provider, and AOL’s sudden, wonderful announcement that all 60+ million AOL/AIM users now have an identity provider.

But where are the OpenID-enabled web applications to log into? What we have so far is nice, but it’s not the kind of riches we’re seeing on the provider side of the OpenID equation.

With Rails being the platform of choice for many new & emerging web sites, you’d expect to see OpenID support here first. So really the question is — Why don’t we see more Rails apps with OpenID support?

  • Most OpenID-enabled sites still need to support password authentication. There are some good choices today for creating a new Rails app that only supports OpenID login (the ruby-openid gem’s generator is good for that), but it’ll be some time before all users are comfortable with OpenID. So sites need to be able to add OpenID support alongside password login — and that’s a non-trivial challenge today (see bookmarks for one example, but it’s not yet solid).
  • Competing authentication plug-ins. For OpenID, there are two major competing plugins: JanRain’s generator that is included in the ruby-openid gem, and Eastmedia’s generator (used in the bookmarks example). And to combine with password authentication, there’s a more confusing jumble of choices. If you’re running Rails 1.2, restful_authentication is currently the strongest choice for password login because of its cleanliness, tests, and feature support for remembered logins (cookies) and optional email activation, etc (<1.2, acts_as_authenticated is strongest). And on the OpenID side, Eastmedia's generator is better configured to mashup with other login systems, but it still requires a substantial amount of customization, and it suffers from lack of tests and some out of sync code.
  • The right user interface hasn’t been settled on. Should we present password & openid login on the same page? A set of choices with fancy UI (tabs)? Should account creation be automatic for OpenID? Should OpenID SRE nickname and email be assumed to be configured?
  • The right internal structure involves some difficult tradeoffs. Just at the top level — should different authentication methods all store their data in a unified user model? Should the application’s login and OpenID’s nickname be treated as equivalent? If so, how to handle uniqueness? etc. etc.
  • Disagreements on the wisdom of drop-in authentication. The best hope for making this all more approachable is better plugin support, including authentication plugins that play well together so a single application can support multiple authentication mechanisms. But there has been some disagreement among the community — some would argue that authentication of this type is too tied to unique aspects of the application and too important from a security point of view to be realistic as a dynamic plugin or works-out-of-the-box generator. But without out-of-the-box ease (like what aaa or restful_authentication provides for password authentication), combined OpenID+password authentication will trail in adoption.
  • In short, the killer OpenID plugin has yet to be written. For an excellent spec for what is needed and an incomplete implementation, see Hark.

OpenID is poised to take off. Support from an army of up-and-coming Rails sites could be the turning point.

Are there other tools that make this more approachable for Rails developers?

Comments (4) to “Why the lack of OpenID-enabled Rails apps?”

  1. Bernie,

    Hi. I’m glad you got a chance to see the Bookmarks app. We have recently updated it for Rails 1.2.2, so it is based on restful_authentication and is fully RESTful (at least according to the Rails interpretation of REST). We completely agree that developing an idiom for a dual-login system that offers the same simplicity and convenience of the acts_as_authenticated / restful_authentication plugins is difficult. We hope the Bookmarks app can help demonstrate what such a setup might look like.

    Please take a look at the current branch of the RESTified app, which works out of the box. We would love to hear any thoughts and suggestions about how to simplify it without getting in the way of app-specific requirements.

    http://svn.eastmedia.com/svn/bantay/projects/bookmarks/branches/restified/

    We’re cleaning up the tests and a few minor issues, but it works as expected. We’ll be pushing some changes into a restful version of the consumer plugin soon. See docs/README_FOR_APP.

    Good luck!

    Thanks,
    Matt

  2. Thanks, Matt. Thanks for all the great Eastmedia Ruby-OpenID work!

    Some of the trouble I had with the bookmarks sample app was because the trunk (at least up to Revision 11) used open_id_fields['openid.sreg.nickname'] in the complete() method, instead of open_id_fields['nickname']. I didn’t track down when ruby-openid made this (breaking?) change to shorten the sreg keys, but the new restified version you linked to does use open_id_fields['nickname'].

    This is a great sample to iron out, because it does combine pwd & openid auth and you all have the experience to turn it into an effective plugin. Thanks!!

  3. I think that the hassles of integrating and maintaining any library, whether on Rails or any other framework, is a big reason why there aren’t more OpenID-enabled web applications. Most folks want to focus on their apps, and this identity stuff isn’t super easy to deal with.

    I posted on an idea that I think might be able to address this and also the issues of drop-in authentication and continued username / password use you mention. Check it out:

    http://www.econometa.com/archives/51

    Do you think this kind of tool would make it easier for developers to support OpenID?

  4. Here are a couple of rails apps that use OID:

    http://svvarm.com
    http://votemonkey.com

    Although both are useful without any authentication, the community aspects of these applications increases by setting up a user – which may be based on your open id.

    Enjoy.

Post a Comment
(Never published)