Much More to Explore
If you have any previous experience with Rails, you may have noticed that the described implementation didn't use any of the existing traditional authentication frameworks (that is, either
restful_authentication or
act_as_authenticated). This is again an indication that OpenID authentication does not depend on any previously established authentication logic.
In addition, if you want to avoid the dependency on the Rails open_id_authentication plugin or you need greater flexibility, you can access the ruby-openid library directly. Listing 2 shows an alternative (and longer) login controller that uses the ruby-openid function calls and public classes directly. To differentiate it even further, it uses the filesystem (instead of the database used up to this point) to store the temporary data required throughout the handshaking between your application and the OpenID provider.
The advantages of the OpenID service are clear: less code duplication, complexity, and maintenance overhead for the developer and a more coherent web experience for the user. However, this article went through only the very superficial layers of the OpenID universe, leaving a lot of other features open to exploration. These include the new OpenID 2.0 specification, the service discovery and delegation mechanisms, the Extensible Resource Descriptor Sequence (XRDS) format, stateless relying parties, and many others.
Also, many parts of the ruby-openid library were not explored. For example, it also supports setting up a Rails OpenID provider, instead of just the client library for a relying party as described in the article. Thanks to the openness of the OpenID initiative, you can further explore the service in as much details as you may need.
Previous Page
