Many software applicationsincluding websitesoffer features that are only available to users who first log-in to the system. In a typical application, user identity is confirmed ("authenticated") upon entering the username and password for the account. This approach is straightforward and works, but there are drawbacks. For instance, most apps reinvent the wheel when it comes to authentication, and many do-it-yourself implementations are easily exploited because developers may not have expertise in security. Users are usually required to remember a username/password for every application they use, which can be problematic.
OpenID (www.openid.net) is an open standard that defines a way that web-based applications ("consumers") can authenticate users by delegating the responsibility of authentication to identity providers. With OpenID, users have a single identity that can be used on any OpenID-enabled application, and they only need to remember one password.
In this article, I describe the OpenID authentication system and show how a web application built with Ruby on Rails can use OpenID to authenticate its users.
How OpenID Works
OpenID relies on the HTTP protocol to exchange messages between "consumers" and "identity providers." Consider a user named Bob, whose identity provider is myOpenID (www.myopenid.com). Bob uses the Drupal content-management system that happens to be an OpenID consumer. Here's the general workflow when Bob logs into his Drupal account through OpenID:
- Bob visits his Drupal-driven website.
- Bob enters his OpenID identity URI, "bobs-id.myopenid.com," in the login form and clicks a Submit button. That's his OpenID identity URI, which looks like a website address, but identifies Bob and his identity provider.
- Bob's web browser is redirected to a web page served by myOpenID, where he is prompted for his password.
- Bob enters his OpenID password and clicks a Submit button.
- myOpenID confirms Bob's password, and his web browser is redirected to Drupal with some information about Bob.
Bob entered his password only on the identity provider website, and never on the consumer website. The user's password is not shared with the consumer and only needs to be submitted once by users to the identity provider, preferably over a secure connection.
OpenID provides several benefits to users and developers. Users only need to remember one username (their identity URI) and password to access multiple applications. With a simple cookie and Remember Me checkbox, an OpenID identity provider can act as a convenient Single Sign-On (SSO) solution for someone who uses multiple OpenID consumers.
OpenID identity providers are responsible for the authentication of users, giving web developers one less thing to understand, implement, and maintain, and letting them focus on core business. Supporting OpenID removes a barrier to entry for many potential users who balk at yet another website asking them to sign up.
It's not uncommon for web apps to offer OpenID support as an alternative to traditional authentication methods, but letting experts handle password security reduces the risk of accounts being compromised.